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 When a site receives a BGP "discovery" update message, the BGP speaker must not send that update message to its neighbor unless there is at least one lightpath available to that neighbor. This assures that "discovery" updates are received only if there is a feasible lightpath to the site that sourced the update message. As an example, in the following example if B sends "discovery" messages to its neighbor BGP peer Z. If Z has lightpaths available to Y but none to U, Z will send that message to Y only. <-- <-- A ----- X ----- Y ----- Z ----- B \ / \ / W ------- U Sites receiving the lightpath discovery update know that there is a possible lightpath to the destination site defined through is AS number and network prefix(es). The AS_PATH constructed along the way also contains the optical sites that the lightpath will go through if it is established. 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 IP address of the destination site egress OXC - The reachable IP prefixes through that candidate lightpath - 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 BGP update message used to establish a specific lightpath contains the AS_PATH information and unique identifier obtained in the discovery phase. This information should be included in a "to-be-defined" attribute. Upon receiving a lightpath establishement update message, a BGP peer should discard the message it does not contain that site AS in the attribute (tbd). This way, we make sure that the establishement update message gets processed only by the identified AS in the attribute. (to be completed) 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