Network Working Group Marc Blanchet Internet Draft Florent Parent Expiration: August 2001 Viagenie Bill St-Arnaud Canarie March 2001 Optical BGP (OBGP): InterAS lightpath provisioning draft-parent-obgp-01.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as _work in progress._ The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This work investigates inter-AS lightpath provisioning using BGP. BGP is currently deployed across the different autonomous systems on the Internet, so investigating how a BGP approach to provision lightpaths across autonomous systems is of great interest. This work proposes extensions to BGP to this end. 1. Introduction Much of the current work in IP optical focuses on using interior gateway protocols such as ISIS and OSPF with TE extensions for routing and GMPLS for signaling [ISIS-TE], [OSPF-TE], [CRLDP], [RSVP-TE]. This draft considers optical lightpath provisioning at the inter-AS scope. Other protocols may be use inside the autonomous system to control the actual optical cross-connect (OXC). BGP [BGP] is currently deployed across the different autonomous systems on the Internet, so investigating how a BGP approach to provision lightpaths across autonomous systems is of great interest. The goal of this work is to propose a BGP approach to lightpath provisioning. 2. Scope The traditional networks are carrier based and the carrier manages the customer transit connectivity. Customers are now acquiring fibre, optical switch ports and wavelengths and this changes the traditionnal model of network peering. Customers in sites can now own their own wavelengths, and eventually optical switch ports. Providers can deploy an optical infrastructure and sell wavelengths and optical switch ports to their customers. Customers now have multiple wavelengths and optical ports from one or many providers. This ownership of wavelengths and optical ports now brings new operational requirements where customers at the edge need to control a subset of lightpaths within another network's wavelength cloud (provider) so that they can manage their own lightpath routing within that cloud. This new model allows distributed Internet Exchange facilities using the exchange and trading of lightpaths between networks to minimize the need for hierarchical network architectures to interconnect peering networks. As an example, CA*net4 optical network in Canada could provide lightpath transit to Renater/France and Wide/Japan networks. The scenario that is considered in this document is where autonomous sites own their wavelengths and optical switch ports. End customer have "virtual" control over its optical switches/ports/wavelengths. The document covers inter-AS provisioning using BGP. Inside an autonomous system, other protocols can be used, such as OSPF or ISIS with TE extensions for routing and GMPLS for signaling. 3. Protocol operation It is assumed that a BGP peering is already established between participating sites, either using a non-optical path or a pre-configured optical path between sites. This BGP peering will be used in the following description. The (egress) OXC are BGP speakers. The OXC and the BGP router are closely tied together in the sense that information received from BGP will be used to establish optical cross-connects inside the OXC. The sites are eBGP peers. This document doesn't specify any intra-AS routing and signaling protocols for lightpath provisioning, although interaction between the inter-AS and intra-AS protocols will need to be defined. The protocol proposes two phases. The first phase is the lightpath reachability phase. During this phase, sites advertise through BGP the availability of the optical lightpath to their site. These announcements will contain information on the OXC and the available lightpath through that OXC. The information will be encoded using multiprotocol BGP extensions and extended community. This first phase will allow sites to build up a "lightpath RIB" that will be used to determine if a lightpath is feasible across a number of OXC in different sites. The second phase is the lightpath establishement. This phase uses the information received from the lightpath reachability phase and then uses a BGP update message to communicate the lightpath establishement to the OXC sites on the path. The information will be encoded using multiprotocol BGP extensions and extended community. 4. Encoding Optical Lightpath information in BGP The BGP Multiprotocol extensions [BGP-MP] allow BGP to carry routes from multiple "address families". This document proposes to use MP-BGP extensions to encode the NLRI such that the necessary optical and routing information can be propagated in BGP. Figure 1 presents the MP_REACH_NLRI attribute format. +----------------------------------------------------+ | Address Family Identifier (2 octets) | +----------------------------------------------------+ | Subsequent Address Family Identifier (1 octet) | +----------------------------------------------------+ | Length of Next Hop Network Address (1 octet) | +----------------------------------------------------+ | Network Address of Next Hop (variable) | +----------------------------------------------------+ | Number of SNPAs (1 octet) | +----------------------------------------------------+ | SNPA | ~ ~ +----------------------------------------------------+ | Network Layer Reachability Information (variable) | +----------------------------------------------------+ Figure 1. The address family identifier (AFI) represents the type of network layer protocol used in the protocol. Since IP is used, the AFI value is either 1 for IPv4 addresses or 2 for IPv6 addresses. The subsequent address family identifier (SAFI) indicates what type of information is carried in the NRLI. The NLRI will encode the necessary information about the optical cross-connect (OXC) endpoint and the reachable networks through that OXC. This document proposes using a SAFI value of 131, which is part of the private use range. If this proposal goes to standard track RFC, then an IANA assigned number should be defined as defined in [BGP-MP]. The necessary information to be carried inside BGP are: - the IP address of the site egress OXC - The reachable IP prefixes - A lightpath identifier The following sections will describe each of those items. 4.1 IP address of the local OXC and reachable IP prefixes The update message includes the IP address of the local OXC. This allows a site to determine if a lightpath has already been established to the destination OXC [OROUTING]. The IP address of the local OXC is encoded in the NLRI as showned in figure 2. The reachable IP prefixes are used by remote sites to determine what networks can be reached through the announced lightpath availability. The reachable IP prefixes are carried in the NLRI, also showned in figure 2. +----------------------------------------------+ | Length of the NLRI (2 octets) | +----------------------------------------------+ | Length of OXC IP address (2 octets) | +----------------------------------------------+ | OXC IP address (variable) | +----------------------------------------------+ | Length of Reachability Entries (2 octets) | +----------------------------------------------+ | First Reachability Entry (variable) | +----------------------------------------------+ | Second Reachability Entry (variable) | +----------------------------------------------+ ..... +----------------------------------------------+ | N-th Reachability Entry (variable) | +----------------------------------------------+ Figure 2: NLRI encoding Length of the NLRI (2 octets): Total length of the NLRI Length of OXC IP address (2 octets): Length of the OXC IP address OXC IP address (variable): IP address of the OXC Length of Reachability Entries (2 octets): Length of a reachability entry Reachability Entry (variable): Variable length field that lists the feasible routes associated with this update. This is encoded as an NLRI tuple of the form as described in [BGP-MP]. 4.2 Lightpath identifier attribute A site can have one or many lightpaths available to its neighbor OXC. The site may decide to send one message that aggregates all its available lightpaths in one BGP message, or the site may make available some lightpaths for special usage and others for general use. The lightpath reachability update message identifies the lightpath or lightpath bundle using an extended community attribute [BGP-COMM]. Figure 3 shows the format of the lightpath identifier attribute. The extended community attribute is 8 octets long. +--------------------------------------+ | Type (2 Octets) | +--------------------------------------+ | source AS (2 Octets) | +--------------------------------------+ | reserved (2 Octets) | +--------------------------------------+ | Lightpath identifier (2 Octets) | +--------------------------------------+ Figure 3: Extended community for lightpath identifier The lightpath identifier can also be used to enforce local policies where a site wants to reserve a number of optical ports for special purposes. In that case, a predefined lightpath identifier can be used between participating sites. The lightpath identifier attribute will be used during both the lightpath reachability and the lightpath establishement phases. The value(s) and length of the lightpath identifier attribute will need to be further defined. 4.3 Capability Negociation A BGP speaker that uses the BGP messages described in this document should use the capability advertisement defined in [BGP-CAP]. This will allow a speaker to determine if a peer supports the multiprotocol extensions defined in this document. The capability negociation should use the AFI and SAFI values of (to be completed) 5. First phase: Lightpath reachability In this first phase, the sites advertise lightpath availability to other sites using BGP lightpath reachability update messages. This message contains the following information: - The IP address of the site egress OXC - The reachable IP prefixes - A lightpath identifier The IP address of the site egress OXC and the reachable IP prefix through that announced lightpath are encoded as described in section 4.1. The lightpath identifier is an extended community attribute encoded as described in section 4.2. The type field uses a value of 0xA101 to denote that the message contains a lightpath reachability message. The type field value is chosen from the vendor-specific range [BGP-COMM]. If this proposal goes to standard track RFC, then an IANA assigned number should be defined as defined in [BGP-COMM]. The reserved field has a value of 0x00 when the type field is 0xA101 (lightpath reachability message). The lightpath identifier value is assigned by the local organisation. +--------------------------------------+ | Type (2 Octets) = 0xA101 | +--------------------------------------+ | source AS (2 Octets) | +--------------------------------------+ | 0x00 | +--------------------------------------+ | Lightpath identifier (2 Octets) | +--------------------------------------+ Figure 4: Extended community for lightpath identifier The following is an example of BGP speakers connected together through the connexions shown in figure 5. A ----- X ----- Y ----- Z ----- B \ / \ / W ------- U Figure 5. To illustrate the process, the following table shows what the local-RIB at sites A and U would look like when updates from all sites are received. Note that the extended-community shows the type 0xA101 (lightpath reachability message), the AS number of the originating site and a lightpath identifier. The identifier used here is of the form L(xa) and represents one or a bundle of available optical ports on the originating site (in this case, site X). The value of this identifier is choosen by the local site. Destination OXC_IP Next-Hop extended-community AS-path ----------- ------ -------- ------------------ ------- Network X IP_X IP_X 0xA101,X,L(xa) X Network Y IP_Y IP_X 0xA101,Y,L(yx) X,Y Network Z IP_Z IP_X 0xA101,Z,L(zy) X,Y,Z Network B IP_B IP_X 0xA101,B,L(bz) X,Y,Z,B Network W IP_W IP_X 0xA101,W,L(wx) X,W Network U IP_U IP_X 0xA101,U,L(uw) X,W,U Table 1. Local-RIB at site A Destination OXC_IP Next-Hop extended-community AS-path ----------- ------ -------- ------------------ ------- Network Z IP_Z IP_Z 0xA101,Z,L(zu) Z Network B IP_B IP_Z 0xA101,B,L(bz) Z,B Network Y IP_Y IP_Z 0xA101,Y,L(yz) Z,Y Network W IP_W IP_W 0xA101,W,L(wu) W Network X IP_X IP_W 0xA101,X,L(xw) W,X Network A IP_A IP_W 0xA101,A,L(ax) W,X,A Table 2. Local-RIB at site U Each site is responsible of sending its lightpath availability to its neighbors. If a OXC can no longer offer a previously announced lightpath, it must send a withdrawl. That withdrawl message will contain the same extended-community attributes that were used to announce the previously available lightpath(s). After receiving BGP update messages from its neighbors, a site can choose to request the establishement of a lightpath to that destination sending a lightpath establishement BGP update message. 6. Second phase: Lightpath establishement This work investigates inter-AS lightpath provisioning. BGP is currently deployed across the different autonomous systems on the Internet, so investigating how a BGP approach to provision lightpaths across autonomous systems is of great interest. The goal of this work is to propose a BGP only approach to lightpath provisioning. To this end, this section describes extensions to BGP to signal lightpath establishment between autonomous systems. 6.1 Using BGP for lightpath establishment Following the lightpath reachability phase, a site has the following information for each candidate lightpath: - The reachable IP prefixes through that candidate lightpath - The IP address of the destination site egress OXC - A lightpath identifier - The AS_PATH to the destination site A site can choose to request the establishment of a lightpath from the information received in the lightpath reachability phase. The reachable IP prefix(es) can be used to determine which networks can be reached through the lightpath if that lightpath is established. The IP address of the destination site egress OXC can be used to determine if a lightpath to the OXC has already been established. To illustrate the proposed protocol mechanisms, the following optical topology example is used: A ----- X ----- Y ----- Z ----- B \ / \ / W ------- U Looking more closely at site A, the following local-RIB is formed from the information in the reachability phase: Destination OXC_IP Next-Hop extended-community AS-path ----------- ------ -------- ------------------ ------- Network X IP_X IP_X 0xA101,X,L(xa) X Network Y IP_Y IP_X 0xA101,Y,L(yx) X,Y Network Z IP_Z IP_X 0xA101,Z,L(zy) X,Y,Z Network B IP_B IP_X 0xA101,B,L(bz) X,Y,Z,B Network W IP_W IP_X 0xA101,W,L(wx) X,W Network U IP_U IP_X 0xA101,U,L(uw) X,W,U If site A wants to establish a lightpath to network U, Site A needs to first lookup the "lightpath RIB" entries to find a complete path to the site. The "lightpath RIB" entry for network U on the last line shows that the AS-path is (X,W,U). In order to establish a lightpath to site U, A need to do the following steps: 1- Lookup the RIB entry for the destination site 2- Lookup the corresponding entries for the intermediary sites 3- Allocate optical port and create a BGP "establish" message using the looked up information. In the example, step 1 will lookup the entry: Destination OXC_IP Next-Hop extended-community AS-path ----------- ------ -------- ------------------ ------- Network U IP_Z IP_X 0xA101,Z,L(uw) X,W,U Step 2 will lookup for the intermediate sites, that is the path to (X) and to (X,W): Destination OXC_IP Next-Hop extended-community AS-path ----------- ------ -------- ------------------ ------- Network X IP_X IP_X 0xA101,X,L(xa) X Network W IP_W IP_X 0xA101,W,L(wx) X,W The reason for looking up the intermediate sites entries in the "lightpath RIB" is to make sure that there is a complete path available to the destination site. Lightpath availability on the optical network may change at any time. For example, if the state of site W were to change such that lightpaths were no longer available to reach X from W, W must withdraw its lightpath availability by sending BGP withdrawl of its own lightpath, L(wx) in the example. If that were the case, X would now advertise to A a different path to reach U (X,Y,Z,U) using the standard BGP path selection process. The BGP update message used to establish a specific lightpath contains the AS_PATH information and the lightpath identifiers obtained in the lightpath reachability phase. These information are encoded in extended community attributes. +--------------------------------------+ | Type (2 Octets) = 0xA102 | +--------------------------------------+ | source AS (2 Octets) | +--------------------------------------+ | destination AS (2 Octets) | +--------------------------------------+ | Lightpath identifier (2 Octets) | +--------------------------------------+ Figure 4: Extended community for lightpath establishment message Destination OXC_IP Next-Hop extended-community AS-path ----------- ------ -------- ------------------ ------- Network X IP_X IP_X 0xA101,X,L(xa) X Network W IP_W IP_X 0xA101,W,L(wx) X,W Network U IP_Z IP_X 0xA101,Z,L(uw) X,W,U In order to establish the lightpath, site A must send a BGP update message to its neighbor(s). Site creates a BGP update message using the following extended community attribute: type src AS dest AS lightpath id ---- ------ ------- ------------ 0xA102 A X L(xa) 0xA102 X W L(wx) 0xA102 W U L(uw) The lightpath establishment message is detected by the presence of the extended community attribute type 0xA102. Site A allocates an optical port to be used for the lightpath. This port must be identified to its neighbor OXC. Site A will do that by setting an appropriate the value for L(xa). This assumes that there are some peering/trust relationships between neighboring OXC such that some convention will be agreed upon between such neighbors. Note that the value of L(xa) for this example may and will probably be different from the L(xa) value obtained from the lightpath reachability phase. The lightpath establishment phase requires precise optical port assignements between the neighbors and this is the proposed function here. The port assignement is of local scope and is significant only to neighboring OXC. Site A sends the BGP message to its neighbors. Upon receiving a lightpath establishment update message, a BGP peer should discard the message if its AS is not part of the destination AS in the extended community attribute. This way, the establishment update message gets processed only by the identified AS in the attribute. Upon receiving the update, OXC X will have the information to do the cross-connect to site A using the value L(xa), and assign an optical port from the requested "bundle" L(wx). Again, OXC X will set the value for L(wx) that identifies the allocated optical port. The local RIB of each OXC will have a new entry that identifies the establish/allocated lightpath. 6.2 Using RSVP-TE or CR-LDP for lightpath establishment (to be completed) The purpose of this section is to look at current signaling protocols to provision lightpaths and how they could be used in the inter-AS context, define the interaction with BGP. 7. Routing information exchange When the lightpath is established, a new BGP peeringis established between the two peers that are now directly connected together on the new established lightpath. 8. Interaction with Intra-AS IPO protocols Since the lightpath to be established can cross multiple ASes, then there should be propagation of the requested lightpath inside the crossed AS. This should be done by redistributing the lightpath request parameters in the IPO intraAS protocol (to be completed) 9. Issues to be solved - how to unprovision: through a withdrawal, but details to be discussed - multiple reservations at the same time, reservations not being used that should be discarded: typical reservation problems. - Lightpath identifier: currently an extended attribute. Encode in MP_NLRI instead ? 10. References [OBGP] CA*Net4, Bill St-Arnaud. [BGP4] Y. Rekhter, et al., "A Border Gateway Protocol 4 (BGP-4)", Work in Progress, draft-ietf-idr-bgp4-12.txt, Jan 2001 [BGP-COMM] Ramachandra, Tappan, "BGP Extended Communities Attribute", Work in progress, draft-ramachandra-bgp-ext-communities-08.txt, February 2000 [BGP-MP] Bates, T., et al., "Multiprotocol Extensions for BGP4", RFC 2858, June 2000. [BGP-CAP] R. Chandra, J. Scudder, "Capabilities Advertisement with BGP-4" RFC 2842, May 2000 [OROUTING] Dimitris Pendarakis, et al., "Routing Information Exchange in Optical Networks", Work in Progress, draft-prs-optical-routing-01.txt [BGPVPN] Hamid Ould-Brahim, et al., "Using BGP as an Auto-Discovery Mechanism for Network-based VPNs", Work in Progress, draft-ouldbrahim-bgpvpn-auto-00.txt, November 2000. [CRLDP] Peter Ashwood-Smith, et al., "Generalized MPLS Signaling - CR-LDP Extensions", Work in Progress, draft-ietf-mpls-generalized-cr-ldp-00.txt, November 2000. [RSVP-TE] Peter Ashwood-Smith, et al., "Generalized MPLS Signaling - RSVP-TE Extensions", Work in Progress, draft-ietf-mpls-generalized-rsvp-te-00.txt, November 2000. [ISIS-TE] Kompella, K., et. al. "IS-IS Extensions in Support of Generalized MPLS", Work in Progress, draft-ietf-isis-gmpls-extensions-01.txt, November 2000. [OSPF-TE] Kompella, K., et. al. "OSPF Extensions in Support of Generalized MPLS", Work in Progress, draft-ietf-ospf-gmpls-extensions-00.txt, November 2000. 11. Security Considerations - Provisioning on demand new lightpaths changes the network infrastructure and the routing tables. This should only be done using strong authentication. - Authentication measures in BGP must be used. 12. Acknowledgements The OBGP acronym, the seminal ideas as well as most of the thinking are from Bill St-Arnaud. 13. Authors' Addresses Marc Blanchet Viagenie 2875 boul. Laurier, bureau 300 Sainte-Foy, QC G1V 2M2 Canada Marc.Blanchet@viagenie.qc.ca Florent Parent, Viagenie Viagenie 2875 boul. Laurier, bureau 300 Sainte-Foy, QC G1V 2M2 Canada Florent.Parent@viagenie.qc.ca Bill St-Arnaud Canarie 110 O'Connor, 4th floor Ottawa, ON, K1P 1H1 Canada Bill.St.Arnaud@canarie.ca