“ BGP based Auto-Discovery Mechanism for Optical VPNs” <draft-fedyk-bgpvpon-auto-00.txt> Don Fedyk Hamid Ould-Brahim Peter Ashwood-Smith (Nortel Networks) Yakov Rekhter (Juniper Networks) Eric C. Rosen (Cisco Systems) 50 th IETF, Minneapolis, March 2001
Motivations/Requirements • Define a BGP based auto-discovery mechanism which allows client devices (CDs), members of the same VPN to discover themselves and to request CD-to-CD optical connections across a service provider optical infrastructure. • Optical VPN (OVPN) is defined as a collection of ports that connect the CDs owned by the same organization to the service provider network. • A given service provider network could support multiple OVPNs.
• A port is actually a collection of channels (e.g., lightpath, SDH/SONET circuit). • Not all ports on a given provider edge optical network element (PE-ONE) that connect that PE ONE to CDs must belong to the same OVPN. • One important goal of the mechanism is to support single ended provisioning. • It should be possible to reconfigure OVPN (e.g when CD request to setup a new optical channel trail to another CD within the same VPN) without requiring configuration changes in any of the provider's ONEs.
Reference Model P P CD1 CD2 PE2 PE1 CD5 CD4 CD3 PE4 PE3 CD7 CD6 P P VPON A VPON B CD4 CD5 CD1 CD2 CD7 CD6 CD3
Mode of Operations • Within a given OVPN, each port has an identifier unique only within that OVPN called the Customer Port Identifier (CPI). • Within a service provider network, each port on a PE ONE has an identifier that is unique within that service provider network. We refer to this identifier as Provider Port Identifier (PPI). • Each PE ONE maintains a Port Information Table (PIT) for each OVPN that has at least one port on that PE ONE. A PIT contains a list of <CPI, PPI> tuples for all the ports within its OVPN.
CPI= <interface index, CD IP address> Unique number Unique address within the CD within the OVPN PPI= <interface index, IP address> Unique number Unique address within the PE within the SP network (per port) Port Information Table (PIT) <CPI, PPI> . .
OVPN Components Provider Edge ONE (PE) Provider Edge ONE (PE) VPN A VPN-A VPN A PIT PIT VPN A CD1 CD2 BGP information Distribution VPN B VPN B VPN B VPN B Backbones CD1 BGP PIT PIT BGP CD2 GMPLS based VPN C VPN C VPN C VPN C CD1 PIT PIT CD2 A PIT on a given PE ONE is populated from two sources: the information received from the CDs attached to the ports on that PE ONEs, and the information received from other PE ONEs (received through BGP).
How the mechanism works? CD1 PE1 PE2 CD2 PIT-1 configured PIT-2 with a list of import/export route targets <CPI-1> <CPI-2> Build <CPI-1, PPI-1> on PIT-1 PIT-2 BGP_MP Information distribution to PEs <CPI-1> Receive information PIT-2 <CPI-2> <CPI-2,PPI-2> stored in PIT-1 GMPLS: request connection <CPI-1,CPI-2> GMPLS: request GMPLS: PIT-1 <CPI-1,PPI-1>,<CPI-2,PPI-2> request connection <CPI-1,CPI-2> PIT-2 Optical connection
• A CD need not establish an optical connection to every target port that CD knows about. Therefore the VPON topology is controlled by the CDs. • A port, in addition to its CPI and PPI may also have other information associated with it (e.g., characteristics of the channels within that port like encoding , bandwidth , total unreserved bandwidth within the port, etc). • The connectivity between CDs is established at the granularity of channels
Others • The mechanism applies also to a situation where the service provider network consists of SONET/SDH cross connects and ports are connected via SONET/SDH sub-channels with each other. • Since the protocol used to populate a PIT with remote information is BGP, and since GMPLS signaling isn't restricted to a single routing domain, it follows that this mechanism could support an environment that consists of multiple routing domains.
Recommend
More recommend
