Network Working Group Marc Blanchet Internet Draft Florent Parent Expiration: July 2001 Viagenie Bill St-Arnaud Canarie January 2001 Optical BGP (OBGP): InterAS lightpath provisioning draft-parent-obgp-00.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 Current work in IP optical focuses on designing interior gateway protocols for use in optical, such as OSPF/TE and MPLamdaS. (TBD: add references) 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 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. 2. Scope - is inter-AS, not intra-AS. - inside AS can be iBGP or IGP with IP optical extensions, MPLamdaS, etc. Interaction between intra-AS and inter-AS protocols will need to be defined. - End customer own the fiber or wavelength - End customer have "virtual" control over its optical switches/ports/wavelengths. Some trust exists between AS that are offering the wavelengths. - Typical example: a lightpath established from Renater-France through CA*net4-Canada to Wide-Japan interAS between provinces in Canada, but intraAS inside each province. [OBGP] 3. Requirements TBD 4. Encoding Optical Lightpath information in BGP The BGP Multiprotocol extensions [BGP-MP] allow BGP to carry routes from multiple "address families". MP-BGP extensions are used to encode the NLRI such that the necessary optical and routing information can be propagated in BGP. +----------------------------------------------------+ | 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. The necessary information to be carried inside BGP are: - the IP address of the site egress OXC - The reachable IP prefixes - A lightpath/site 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 establish 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 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 "discovery" 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 A site may have local policies about which sites (AS) are allowed to reserve a lightpath. As an extended community attribute, the lightpath identifier attribute can then be used to apply such policies in BGP. 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. Protocol operation Assume BGP peering is already established between participating sites, either using a non-optical path or a pre-configured optical path between sites. In the following description, we assume that the OXC are BGP speakers. The OXC and the BGP router are closely tied together. The sites are eBGP peers. The protocol proposes two phases. The first phase is the lightpath discovery phase. During this phase, sites advertise through BGP the availability of the optical lightpath to their site. The second phase is the lightpath establishement. This phase uses the information received from the discovery phase and then uses a BGP update message to communicate the lightpath establishement to the OXC sites on the path. This document proposes extensions to BGP for the lightpath establishement. 5.1 Lightpath discovery In this first phase, the sites advertise lightpath availability to other sites using BGP "discovery" 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 "discovery" message. The type field value is chosen from the vendor-specific range [BGP-COMM]. The reserved field has a value of 0x00 when the type field is 0xA101 (discovery 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 A ----- X ----- Y ----- Z ----- B \ / \ / W ------- U Figure 5. To illustrate this 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 (discovery message), the ASN 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_Z IP_X 0xA101,Z,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 The lightpath identifier will be used in the lightpath establishement phase ... (TBC) 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 (R&D, universities, etc...). In that case, a predefined lightpath identifier can be used between participating sites. Each site is responsible of sending its lightpath availability to its neighbors. If a OXC can no longer offer lightpaths, it must send a withdrawl message to its BGP peers to announce that condition. That withdrawl message will contain the same extended-community attributes that were used to announce the previously available lightpaths. Upon receiving a BGP update message from a site, the destination site can choose to request the establishement of a lightpath to that destination sending a lightpath establishement BGP update message. 5.2 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 will describe extensions to BGP to signal lightpath establishement between autonomous systems. We will also investigate and compare to current work on existing signaling protocols, such as extensions to CR-LDP and RSVP. TBD: Reference current working documents at IETF on proposed signaling protocols for establishing lightpath on an IP optical network (extensions to CR-LDP, RSVP) 5.2.1 Signaling requirements (TBD) 5.2.3 Using BGP for lightpath establishement Following the lightpath discovery phase, a site has the following information for each candidate lightpaths: - 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 establishement of a lightpath from the information received in the lightpath discovery phase. The reachable IP prefix can be used to determine if a lightpath to that site is desirable, for example a site can determine that a lightpath to a particular destination would ... (TBC) 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, we take the following optical topology example: A ----- X ----- Y ----- Z ----- B \ / \ / W ------- U Looking more closely at site A, we have the following local-RIB populated from the information in the discovery 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_Z IP_X 0xA101,Z,L(uw) X,W,U If site A wants to establish a lightpath to network U, Site A needs to first lookup the local-RIB entries to find a complete path to the site. The RIB entry for network U shows that the AS-path is (X,W,U). The required steps are: 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 message "establish" using the looked up information. In our 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 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 W, W must withdrawl its lightpath availability by sending BGP withdrawl of its own lightpath, L(wx) in our example. If that were the case, site A would detect that unavailability in step 2 and would not be able to proceed. TBD: (In that case, the path to U advertised from X to A would go through X,Y,Z,U instead since X will detect the non-availability and the BGP path selection will choose the other path instead. Need to pick another example...) The BGP update message used to establish a specific lightpath contains the AS_PATH information and unique identifier obtained in the discovery 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 establishement 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 Site A needs to create 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 establishement 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). We are assuming 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 discovery phase. The lightpath establishement 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 establishement update message, a BGP peer should discard the message if its ASN is not part of the destination AS in the extended community attribute. This way, we make sure that the establishement 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. (TBD: The multiprotocol NLRI. Is it necessary? If so, what information should encode?) 5.2.3 Using RSVP for lightpath establishement (to be completed) 5.2.4 Using CR-LDP for lightpath establishement [CRLDP] CR-LDP uses TCP as transport protocol. We can use CR-LDP as a signaling protocol between the border OXC that would provide the necessary signaling to establish the required lightpaths. Extensions to CR-LDP are defined for support of optical lightpath signaling. CR-LDP extensions for optical networks [CRLDP] defines the following extensions. These optical attributes can be obtained from the lightpath discovery phase using BGP. (to be completed) 6. Routing information exchange When the lightpath is established, a new BGP process is started to establish a new BGP peering session between the two peers that are now directly connected together on the new established lightpath. 7. 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 (either extended IGP or MPLS or...). Further work has to be done on this. 8. Issues to be solved - how to unprovision: probably 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. - if the lightpath breaks at some point, how does the BGP session handles this? 9. References [OBGP] CA*Net4, Bill St-Arnaud. [BGP-COMM] Ramachandra, Tappan, "BGP Extended Communities Attribute", February 2000, work in progress [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 [RSVP] R. Braden, et al., "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, Sept 1997 [OROUTING] Dimitris Pendarakis, et al., "Routing Information Exchange in Optical Networks", Work in Progress [BGPVPN] Hamid Ould-Brahim, et al., "Using BGP as an Auto-Discovery Mechanism for Network-based VPNs", Work in Progress [CRLDP] Peter Ashwood-Smith, et al., "Generalized MPLS Signaling - CR-LDP Extensions", Work in Progress 10. 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. 11. Acknowledgements The OBGP acronym, the seminal ideas as well as most of the thinking are from Bill St-Arnaud. 12. 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