INTERNET DRAFT Vijayanand C Expiration Date: July 2007 HCL Technologies Somen Bhattacharya Avici Systems A BGP based method to compute inter-AS Traffic engineering Label Switched Paths with PCE draft-vijay-somen-pce-bgp-interas-te-path-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. This Internet-Draft will expire on July, 2007. Copyright Notice Copyright (C) The IETF Trust (2007) Vijayanand et al. [Page 1] INTERNET DRAFT BGP extensions for PCE inter-AS path January 2007 Abstract The ability to compute an optimal path for setting up Traffic engineering Label Switched Paths spanning multiple autonomous systems managed by different operators has been a key requirement in MPLS and GMPLS networks. This document specifies a method of computing inter-AS paths consisting of a list of ASes to be traversed and a list of TE-Tunnels to be traversed in each AS. The method described here uses BGP speakers in the PCEs of each AS to distribute the inter-AS connectivity information and the TE-Tunnels in each AS to its neighbors to facilitate the construction of an inter-AS topology graph which can be used for computing inter-AS paths. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC-WORDS]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview of proposed approach . . . . . . . . . . . . . . . 4 4. Extensions to BGP . . . . . . . . . . . . . . . . . . . . . 5 4.1 PCE-AS-TE Object . . . . . . . . . . . . . . . . . . . 6 4.1.1 Link Type Sub-TLV . . . . . . . . . . . . . . . 7 4.1.2 Link ID Sub-TLV . . . . . . . . . . . . . . . 7 4.1.3 Point to Point inter-AS Link sub-TLV . . . . . . 7 4.1.4 Multi_Access Inter-AS Link sub-TLV . . . . . . . 8 4.1.5 TE-Tunnel sub-TLV . . . . . . . . . . . . . . . 9 4.1.6 Maximum Bandwidth sub-TLV . . . . . . . . . . . 11 4.1.7 Maximum Reservable Bandwidth sub-TLV. . . . . . 11 4.1.8 Link Available Bandwidth sub-TLV . . . . . . . .11 4.1.9 Link TE Metric sub-TLV . . . . . . . . . . . . 12 4.1.10 Link TE Group sub-TLV . . . . . . . . . . . . 13 4.2 GMPLS Link TE Properties Advertisement . . . . . . . . 13 4.2.1 Link Protection Type . . . . . . . . . . . . . 14 4.2.2 Shared Risk Link Group (SRLG) . . . . . . . . 15 4.2.3 Interface Switching Capability Descriptor . . 15 5. Path Computation Methodology . . . . . . . . . . . . . . . 18 6. Interoperability Considerations . . . . . . . . . . . . . . 23 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 23 8. IANA considerations . . . . . . . . . . . . . . . . . . . . 23 9. Security Considerations . . . . . . . . . . . . . . . . . . 23 10. Issue and Future considerations. . . . . . . . . . . . . . 23 11. Authors Addresses. . . . . . . . . . . . . . . . . . . . . 24 12. References . . . . . . . . . . . . . . . . . . . . . . . . 24 Vijayanand et al. January 2007 [Page 2 ] INTERNET DRAFT BGP extensions for PCE inter-AS path January 2007 1. Introduction The requirements for inter-area and inter-AS MPLS Traffic Engineering have been developed by the Traffic Engineering Working Group (TE WG) and have been stated in [RFC4105] and [RFC4216], respectively. In [PD-PATH-COMP], a method to setup inter-domain TE lsps is described wherein the path is computed during the signaling process on a per-domain basis by the entry boundary node of each domain. This method, however, does not guarantee to find an optimal inter- domain constrained path or to efficiently compute a set of inter- domain diversely routed TE LSPs. In [BRPC], a method to optimally compute a inter-domain TE path for MPLS and GMPS LSPs using the PCE architecture detailed in [PCE_ARCH] is described. However the method described requires the list of Autonomous systems or domains to be determined apriori. Determining the list of ASes/domains to be traversed to reach a destination, satisfying the TE constraints is non-trivial. It requires knowledge of the inter-AS connectivity and the TE characteristics of the inter-AS links along with the knowledge of the available paths within each of the ASes/domains. BGP contains information on the list of ASes to be traversed to reach a destination, however BGP route selection and decision process truncates most of the feasible paths, and it also does not carry the TE characteristics of the inter-AS links and path availability within a domain. The objective of this document is to propose a method to find out a list of inter-AS paths to reach a given destination by constructing an inter-AS topology graph on the PCE using a new TE object in BGP to carry the inter-AS connectivity information. This new BGP object called the BGP-TE-AS object carries the inter-AS TE links and TE Tunnels, with known TE metric between the ingress and egress of each AS. The TE tunnels span the entire AS, between ASBRs and may be inter-area tunnels. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [RFC-WORDS]. The reader is assumed to be familiar with the terminology in [PCE- ARCH] and [PCE-DISCO-IGP] AS : Autonomous system Vijayanand et al. January 2007 [Page 3 ] INTERNET DRAFT BGP extensions for PCE inter-AS path January 2007 ASBR : Autonomous System Border Router Inter-AS TE LSP : A TE LSP whose path crosses one or more ASes or sub ASes NLRI : Network Layer Reachability Information PCC : Path Computation Client. An entity or application requesting path computation from a Path computation element PCE : Path Computation Element. An entity or application capable of computing paths over a network topology subject to constraints. TE LSPs : Traffic Engineered Label Switched Path 3. Overview of proposed Approach In this section, we briefly outline the proposed method to compute paths for inter-AS TE LSPs. As per the [PCE-ARCH], each AS MAY consist of one or more PCEs with different path computation capability and scope.These PCE must be participating in the BGP protocol. The PCE shall learn the TE attributes of the inter-AS TE links and the TE tunnels that exist between the ASBRs in the domain. These information can be manually configured in the PCE or can be discovered by some other means. The TE tunnels would be capable of carrying inter-AS TE traffic and set up between ingress and egress of each AS.The method of setup of these tunnels, their optimality etc. are out of scope of this document,but these TE tunnels could be used as hierarchical LSPs (H-LSP) or LSP-segement(S-LSP) and the inter-AS TE LSP would be tunneled or stitched through it. BGP running on the inter-AS path computation capable PCE MUST distribute the information on the Autonomous system and the TE connectivity using the new PCE-AS-TE object described in this document. This information shall be distributed to E-BGP peers in other autonomous systems and shall be propagated across multiple Autonomous systems. The PCE-AS-TE object is described in more detail in section 4.This shall be carried in the MP-REACH NLRI using a new whose value is . In every AS one BGP speaking PCE must originate this new object. This object shall be sent only to the speakers which have the capability to understand this . It is not necessary for all BGP speakers in an AS to support this AFI,SAFI. It would be sufficient for certain speakers alone, or the PCE speakers alone to support it. But, there should be enough speakers supporting this attribute to relay it between PCEs on different ASes. Vijayanand et al. January 2007 [Page 4 ] INTERNET DRAFT BGP extensions for PCE inter-AS path January 2007 The BGP speakers receiving this object in the MP-REACH NLRI shall propagate this object to their peers supporting this . This information can then be used by the PCEs to construct a network wide AS graph, having TE connectivity information between the various autonomous systems. This graph can be used for CSPF path computation algorithms to compute possible inter-AS paths for TE LSPs. TE tunnels MAY be set up between ingress and egress ASBRs of the different autonomous systems. These TE tunnels can be advertised as TE links in the PCE-AS-TE TLV described below. This information can be combined with the previously constructed inter-AS graph to compute an optimal inter-AS TE path between autonomous systems. The inter-ASBR TE-tunnels would be used as hierarchical TE-LSPs or LSP segment(S-LSP) and serve as a hop in the path of the inter-AS TE tunnel This method does not violate the requirement that the internal topology details of an autonomous system should not be advertised outside it. The information advertised merely consists of inter-AS TE links and TE-tunnels connecting ASBRs within the AS and none of the internal topology information is advertised outside the AS. In this document it is assumed that two autonomous systems are connected by single-hop IP links. The links connecting the autonomous systems may be point to point links or multi-access links. When the ASes are connected by multi-hop IP links, it is assumed that some tunneling mechanism, like IP in IP tunneling or MPLS tunnels would be used so that the link shall be seen by the ASBRs as a single-hop IP link. 4. Extensions to BGP A new object called PCE-AS-TE object shall be defined which shall carry information on the TE capabilities of the inter-AS TE links and the TE-Tunnels capable of carrying inter-AS traffic. This shall be carried inside the MP-REACH NLRI using a new . This shall be the only object which is carried in the Network Information part of the MP-REACH-NLRI. For every AS, a PCE shall advertise the PCE-AS-TE Object. There MUST be only one PCE per autonomous system originating this object on behalf of an AS. The PCE which shall originate this object can be chosen by configuration or by some other means. The capability to support the new which must contain the PCE-AS-TE object shall be advertised in the capability parameter of the open message. The PCE-AS-TE object defined in this document must be advertised only to those PCEs which support the given . The PCE-AS-TE Object shall contain TLVs carrying information on each of the inter-AS TE links and inter-ASBR TE-Tunnels capable of Vijayanand et al. January 2007 [Page 5 ] INTERNET DRAFT BGP extensions for PCE inter-AS path January 2007 carrying inter-AS TE traffic. This object shall be originated when the PCE comes up initially, when the TE attributes of a inter-AS link/TE-Tunnels(such as the bandwidth and metric) changes, when any new inter-AS link/TE-Tunnels comes up or an existing inter-AS link or TE-Tunnel goes down. The PCE shall learn of these events through some means such as IGP flooding of inter-AS links and inter-ASBR TE tunnels or through BGP session between PCE and the ASBRs. An MP-REACH NLRI may contain multiple PCE-AS-TE objects. Each PCE-AS-TE object would be originated by different PCEs in different ASes. The MP-REACH-NLRI has to be completely parsed by the BGP speaker to extract all the PCE-AS-TE Objects. The total length of the MP-REACH-NLRI shall depend on the number of PCE-AS-TE objects carried in it. A PCE-AS-TE object can be uniquely identified by the AS Number and Router ID of the originating router which are carried in it. When the same PCE-AS-TE object is received from multiple BGP peers the local BGP speaker shall select one of the objects using its local BGP decision process using only the general AS path attributes,peer ID etc. and not using any of the attributes in this object. This would result in consistently selecting the PCE-AS-TE object from one of the peers for a given policy configuration, thereby any stale information would not be injected into the PCE during route flaps. The BGP speaker shall store only the selected BGP-AS-TE object and propagate it to its peers. 4.1 PCE-AS-TE Object A new object called the PCE-AS-TE object is defined. This object shall contain a two byte length field, an AS number field, a Router ID field and a variable value field .The value field would consist of a list of Link TLVs. The AS Number field and the Router ID would serve as the key to uniquely identify a PCE-AS-TE object. The PCE-AS-TE object contains a separate Link TLV for each of the inter-AS TE capable links and TE-Tunnels which can carry inter-AS traffic. So, the PCE-AS-TE object shall contain a list of Link TLVs. The AS number would be AS number of the originating PCEs AS. The Router ID would be the router ID of the PCE. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | AS Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Value List of Link TLVs // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vijayanand et al. January 2007 [Page 6 ] INTERNET DRAFT BGP extensions for PCE inter-AS path January 2007 Each Link TLV shall contain the following sub-TLVs : Link Type sub-TLV, Link ID sub-TLV, P2P Local and Remote ASes sub-TLV, Multi- access Local and Remote ASes sub-TLV, Link Maximum Bandwidth sub- TLV, Reservable Bandwidth sub-TLV, Available Bandwidth sub-TLV, Link Colour sub-TLV, Link Metric sub-TLV and Administrative Group sub- TLV. Each of the sub-TLVs contain a two byte type field, a two-byte length field and a value filed. Each of these sub-TLVs is defined below 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // List of sub- TLVs | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.1.1 Link Type sub-TLV The Link Type sub-TLV defines the type of the link: 1 : Point-to-point 2 : Multi-access 3 : TE-Tunnels spanning the AS advertised by PCE The Link Type sub-TLV is TLV type 1, and is one octet in length. 4.1.2 Link ID TLV The Link ID sub-TLV identifies the other end of the link. For point-to-point links, this is derived from the combination of local and remote IP addresses using a standard CRC32 hash on the IP address. For multi-access links, this is derived from the router ID of the router which has the largest router ID on the multi-acces link. The Link ID sub-TLV is TLV type 2, and is four octets in length. 4.1.3 Point to Point inter-AS Link sub-TLV Vijayanand et al. January 2007 [Page 7 ] INTERNET DRAFT BGP extensions for PCE inter-AS path January 2007 The PCE shall use the inter_AS link TLV to carry information on the ASes that the inter-AS links connects. The router IDs of the ASBRs on either side of the link along with the AS numbers of the attached ASes would be carried in this sub-TLV. This sub-TLV must be present only in links which have a link Type of point-to-point in the Link Type TLV. The Type of this sub-TLV is 3 and is 12 octets in length. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local ASBR Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote ASBR Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local AS Number | Remote AS Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.1.4 Multi_Access Inter-AS Link sub-TLV This TLV is used to carry information on multi-access inter-AS links. This sub-TLV must be present only in links which have a link Type of Multi-access in the Link Type TLV. The sub-TLV contains a field for number of remote ASes on the multi-access link,number of remote ASBRs on the multi-access link, Router ID of local ASBR and Router ID of each remote ASBR, Local AS Number and list of remote AS Numbers. The TLV type is 4 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Remote ASes | Number of Remote ASBRs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local ASBR Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vijayanand et al. January 2007 [Page 8 ] INTERNET DRAFT BGP extensions for PCE inter-AS path January 2007 | Remote ASBR Router ID1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote ASBR Router ID2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // List of Remote Router IDs // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local AS Number | Remote AS Number 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // List of Remote ASes // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.1.5 TE-Tunnel sub-TLV TE Tunnels may be setup between different ASBRs of an autonomous system (for pairs of ingress ASBR and egress ASBR) with certain pre- determined TE parameters, to carry inter-AS TE traffic . These TE tunnels would start at the ingress of an autonomous system and end at the egress of the autonomous system. This would span multiple areas within the AS. The setup mechanism of these TE-tunnels and their optimality is outside the scope of this document. These tunnels MAY be advertised as TE links between the ASBRs,into BGP by the PCE and can be used in the overall inter-AS topology graph to compute the inter-AS TE path. The PCE should learn about the inter-ASBR TE tunnels through some means, by configuration or through the IGP or BGP session between ASBR and PCE.The inter-AS TE LSP would then use the pre-established inter-ASBR TE-tunnels. The set-up of inter-ASBR TE tunnels and their advertisement as TE-links into BGP by PCE is entirely the choice of the PCE on the local AS. The policy configuration on the local PCE may permit only certain TE-tunnels to be advertised to other PCEs for carrying inter-AS traffic. Since the TE-Tunnels are setup apriori, sufficient knowledge of the type and nature of inter-AS traffic is needed to setup appropriate TE-Tunnels. This may be the subject of inter-provider agreements on services offerings.These TE-Tunnels may also be setup dynamically based on traffic demand in future. The TE-Tunnel is advertised as a separate link and for each such tunnel the TE-Tunnel sub-TLV shall be used. This TLV type is 5, and length is 12 octets. It contains the router ID of the ingress ASBR, router ID of egress ASBR, and the LSPID. This sub-TLV must be present only in links which have a link Type of TE-Tunnel in the Link Type TLV. Vijayanand et al. January 2007 [Page 9 ] INTERNET DRAFT BGP extensions for PCE inter-AS path January 2007 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ingress ASBR Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Egress ASBR Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSP-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The following diagram depicts a TE-Tunnel and how it is advertise by BGP AS2 . . . . PCE1 . . . . . . AS1 . . AS3 . LSP1 . ASBR1---L1---ASBR2====================ASBR3---L2---ASBR4 . . . . . . . . . . . . . . . . Figure 1. The PCE shall advertise the TE LSP LSP1 in a Link TLV with type TE- Tunnel with local address set to Router ID of the ingress LSR:ASBR2 and remote address set to the router ID of the egress LSR:ASBR3. Vijayanand et al. January 2007 [Page 10 ] INTERNET DRAFT BGP extensions for PCE inter-AS path January 2007 In the same PCE-AS-TE Object inter-AS link L1 and L2 would also be advertised. Therefore, any other PCE receiving the above information can collate them and construct the above topology consisting of inter-AS links connecting the ASBRs and the TE LSPs connecting the ASBR inside the AS. 4.1.6 Maximum Bandwidth sub-TLV The Maximum Bandwidth sub-TLV specifies the maximum bandwidth that can be used on this link, in this direction (from the AS originating the TLV to its neighboring AS), in IEEE floating point format. For TE-Tunnel, the direction is from the ingress to the egress. This is the true link capacity. The units are bytes per second. The Maximum Bandwidth sub-TLV is TLV type 6, and is four octets in length. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Maximum Bandwidth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.1.7 Maximum Reservable Bandwidth sub-TLV The Maximum Reservable Bandwidth sub-TLV specifies the maximum bandwidth that may be reserved on this link, in this direction, in IEEE floating point format. For TE-Tunnel, the direction is from the ingress to the egress. Note that this may be greater than the maximum bandwidth (in which case the link may be oversubscribed). The units are bytes per second. The Maximum Reservable Bandwidth sub-TLV is TLV type 7, and is four octets in length. 4.1.8 Link Available Bandwidth sub-TLV Vijayanand et al. January 2007 [Page 11 ] INTERNET DRAFT BGP extensions for PCE inter-AS path January 2007 The link bandwidth sub-TLV contains the bandwidth availability( reservable bandwidth) at priority levels 0-7 on the link in the direction from the AS originating this TLV to its neighbor. For TE- Tunnel, the direction is from the ingress to the egress. Each value will be less than or equal to the maximum reservable Bandwidth. The units are bytes per second. The TLV type is 8 and length field has the value 32 octets. The available bandwidth is encoded in the standard IEEE-32 floating point format. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Available Bandwidth at Priority 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Available Bandwidth at Priority 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Available Bandwidth at Priority 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Available Bandwidth at Priority 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Available Bandwidth at Priority 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Available Bandwidth at Priority 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Available Bandwidth at Priority 6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Available Bandwidth at Priority 7 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.1.9 Link TE Metric sub-TLV The TE Metric sub-TLV carries the link metric for traffic engineering purposes. This metric may be different than the standard OSPF link metric. Typically, this metric is assigned by a network administrator. The Type of this sub-TLV is 9 and is four octets in length. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Vijayanand et al. January 2007 [Page 12 ] INTERNET DRAFT BGP extensions for PCE inter-AS path January 2007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TE Metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.1.10 Link TE Group sub-TLV The Administrative Group sub-TLV contains a 4-octet bit mask assigned by the network administrator. Each set bit corresponds to one administrative group assigned to the interface. A link may belong to multiple groups. By convention, the least significant bit is referred to as 'group 0',and the most significant bit is referred to as 'group 31'. The Administrative Group is also called Resource Class/Color. The Administrative Group sub-TLV is TLV type 10, and is four octets in length. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group Mask | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.2 GMPLS Link TE Properties Advertisement An inter-Domain topology may consist of MPLS and GMPLS capable LSRs. The GMPLS LSRs may be PSC or non-PSC capable. Also there could be scenarios where the topology would consist of multi-region and/or multi-layer GMPLS networks. Thus it is important that the GMPLS specific Traffic Engineering(TE) properties of such networks are also considered while constructing Inter-Domain TE topology graph for path computation purposes. When the inter-Domain links or the TE links in the form of TE-Tunnel(s) are to be used for GMPLS TE tunnel path layout, the GMPLS specific Traffic Engineering properties of those TE links should also be advertised via Link TLV of the PCE-AS-TE object. These TE Link properties are outlined in [GMPLS-ROUTING]. In this section, we describe the structure of sub-TLVs that would carry those TE Link properties needed for the GMPLS TE links. The following set of sub-TLVs are defined for the Link TLV in support of GMPLS. Vijayanand et al. January 2007 [Page 13 ] INTERNET DRAFT BGP extensions for PCE inter-AS path January 2007 Sub-TLV Type Length Name 14 4 Link Protection Type 15 variable Interface Switching Capability Descriptor 16 variable Shared Risk Link Group 4.2.1 Link Protection Type The Link Protection Type is a sub-TLV of the Link TLV. The type of this sub-TLV is 14, and length of the value field is four octets. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Protection Cap | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The first octet of the value field is a bit vector describing the protection capabilities of the TE link (see Section "Link Protection Type" of [GMPLS-ROUTING]). They are: 0x01 Extra Traffic 0x02 Unprotected 0x04 Shared 0x08 Dedicated 1:1 0x10 Dedicated 1+1 0x20 Enhanced 0x40 Reserved 0x80 Reserved The remaining three octets of the value field SHOULD be set to zero by the sender, and SHOULD be ignored by the receiver. The Link Protection Type sub-TLV may occur at most once within the Link TLV. Vijayanand et al. January 2007 [Page 14 ] INTERNET DRAFT BGP extensions for PCE inter-AS path January 2007 4.2.2 Shared Risk Link Group (SRLG) The SRLG is a sub-TLV (of type 16) of the Link TLV. The length of the value field is the length of the list in octets. The value is an unordered list of 32 bit numbers that are the SRLGs that the link belongs to. The format of this sub-TLV is as shown below: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Shared Risk Link Group-1 Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Shared Risk Link Group-2 Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ............ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Shared Risk Link Group-N Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This sub-TLV carries the Shared Risk Link Group information (see Section "Shared Risk Link Group Information" of [GMPLS-ROUTING]). The SRLG sub-TLV may occur at most once within the Link TLV. 4.2.3 Interface Switching Capability Descriptor The Interface Switching Capability Descriptor is a sub-TLV (of type 15) of the Link TLV. The length is the length of value field in octets. The format of this sub-TLV is as shown below: Vijayanand et al. January 2007 [Page 15 ] INTERNET DRAFT BGP extensions for PCE inter-AS path January 2007 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Switching Cap | Encoding | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at Priority 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at Priority 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at Priority 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at Priority 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at Priority 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at Priority 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at Priority 6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at Priority 7 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Switching Capability-specific Information | | (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Switching Capability (Switching Cap) field contains one of the following values: 1 Packet-Switch Capable-1 (PSC-1) 2 Packet-Switch Capable-2 (PSC-2) 3 Packet-Switch Capable-3 (PSC-3) 4 Packet-Switch Capable-4 (PSC-4) 51 Layer-2 Switch Capable (L2SC) 100 Time-Division-Multiplex Capable (TDM) 150 Lambda-Switch Capable (LSC) 200 Fiber-Switch Capable (FSC) The Encoding field contains one of the values specified in Section 3.1.1 of [GMPLS-SIG]. Maximum LSP Bandwidth is encoded as a list of eight 4 octet fields in the IEEE floating point format, with priority 0 first and priority 7 last. The units are bytes per second. Vijayanand et al. January 2007 [Page 16 ] INTERNET DRAFT BGP extensions for PCE inter-AS path January 2007 The content of the Switching Capability specific information field depends on the value of the Switching Capability field. When the Switching Capability field is PSC-1, PSC-2, PSC-3, or PSC-4, the Switching Capability specific information field includes Minimum LSP Bandwidth, Interface MTU, and padding. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Minimum LSP Bandwidth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface MTU | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Minimum LSP Bandwidth is encoded in a 4 octets field in the IEEE floating point format. The units are bytes per second. The Interface MTU is encoded as a 2 octets integer. The padding is 2 octets, and is used to make the Interface Switching Capability Descriptor sub-TLV 32-bits aligned. It SHOULD be set to zero by the sender and SHOULD be ignored by the receiver. When the Switching Capability field is L2SC, there is no Switching Capability specific information field present. When the Switching Capability field is TDM, the Switching Capability specific information field includes Minimum LSP Bandwidth, an indication whether the interface supports Standard or Arbitrary SONET/SDH, and padding. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Minimum LSP Bandwidth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Indication | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Minimum LSP Bandwidth is encoded in a 4 octets field in the IEEE floating point format. The units are bytes per second. The indication whether the interface supports Standard or Arbitrary SONET/SDH is encoded as 1 octet. The value of this octet is 0 if the interface supports Standard SONET/SDH, and 1 if the interface supports Arbitrary SONET/SDH. The padding is 3 octets, and is used to make the Interface Switching zero Capability Descriptor sub-TLV 32-bits aligned. It SHOULD be set to by the sender and SHOULD be ignored by the receiver. When the Switching Capability field is LSC, there is no Vijayanand et al. January 2007 [Page 17 ] INTERNET DRAFT BGP extensions for PCE inter-AS path January 2007 Switching Capability specific information field present. Since GMPLS allows interfaces to have more than one Interface Switching Capability depending on the underlying technology, the Interface Switching Capability Descriptor sub-TLV may occur more than once within the Link TLV.In such cases a separate Interface Switching Capability Descriptor sub-TLV would be present for each supported Switching Capability (see Section"Interface Switching Capability Descriptor" of [GMPLS-ROUTING]). 5. Path Computation Methodology As described in the previous section the PCE in each AS may advertise its connectivity with neighbouring ASes, as well as TE LSPs connecting ASBRs within its own AS, to all the other PCEs using using the PCE-AS-TE object. For this purpose, apart from the PCEs, some other BGP speakers in the network should also support this extension, in order to carry this information to all the PCEs. The information received in the PCE-AS-TE object, through BGP shall be directly passed on to the Path computation engine residing on the PCE. The Path computation engine on the PCE shall extract the topology information from the PCE-AS-TE objects and compute the path for the inter-AS TE LSPs. When the AS connectivity information is exchanged as described above, the PCEs can construct the inter-AS topology graph consisting of Autonomous systems, ASBRs, inter-AS links and TE-Tunnels connecting the ASBRs within the respective autonomous systems. When such a topology is constructed and the destination is attached to the egress of one of the TE-Tunnels( on the access-network side or on the ASBR itself), it would be possible for PCEs on the ingress AS of a inter-AS TE LSP to compute a suitable path for the TE LSPs in an optimal way using conventional CR-SPF algorithms on the inter-AS connectivity graph. Since the path computation encompasses multiple-ASes, there may be policy constraints on the computing PCE to avoid or include certain ASes in the path computation. This entirely depends on the policy configuration on the local PCE and would be an additional constraint on the path computation algorithm. The destination of a TE-LSP may not be always attached to the ASBRs and the AS in which the destination exists may have multiple ASBRs connecting to the other ASes. In this cases, since the PCEs outside the AS do not know the internal topology of the AS, it would not be possible to compute an optimal inter-AS TE path though there are TE-Tunnels connecting the ASBRs. If the destination AS had only a single ASBR connecting to other ASes, then the PCEs outside the AS could compute the path upto that ASBR and then the PCE in the destination ASBR could compute the path from that ASBR to the destination. This would be optimal since the AS has only Vijayanand et al. January 2007 [Page 18 ] INTERNET DRAFT BGP extensions for PCE inter-AS path January 2007 one ASBR as ingress to it. However, when multiple ASBRs connect the AS to the outside world, it would not be possible to select the appropriate ASBR to optimally ingress the AS since the internal topology would not be known. Therefore, in this case, the PCE on the source AS can only determine the AS path and use it as input to methods such as those described in [BRPC]. In some cases, there may not be TE LSPs between ASBRs which can be used for inter-AS paths. In such scenarios the PCE would have only the inter-AS connectivity graph and no information on the connectivity between the ASBRs within the AS. In these situations,it may not be possible to compute an optimal inter-AS TE path. However, the PCEs can compute a list of possible AS paths to reach the destination AS since the inter-AS connectivity graph is available. The AS attached to the destination of the TE tunnel(Destination AS) itself may be determined from BGP routing information. It can then try to setup TE LSPs along this path, with the list of pre-determined ASes to be traversed, using methods such as those described in [BRPC]. When the path setup along one of the AS path fails the next available AS path can be used for computing the inter-AS TE path using the previous method. The advantage of this method is that, if TE-Tunnels capable of carrying inter-AS traffic are present connecting ASBRs within each AS it becomes possible to compute optimal inter-AS paths without advertising the internal topology details of the Autonomous system. If such TE-tunnels donot exist then the list of possible AS Paths to set up the inter-AS TE LSPs can be automatically determined and methods such as those described in [BRPC] can be applied. In the latter case this supplements the method described in [BRPC]. The method is illustrated with a simple example here. In figure 2. a sample topology consisting of 4 ASes are interconnected. AS2 AS3 . . . . . . . . . . . . . . . . . . . . . . PCE3 . . PCE2 ASBR4.------ .ASBR6 . . // . . \\ . . // . . \\ . AS1 . // . . . . . ASBR7 . . . . . . // . \ PCE1 . . // . \ . . // . . . . . . .ASBR8 ASBR1-----ASBR2=============ASBR3 ----- ASBR5 || . . . . . \\ || . . . . .PCE4 = =ASBR9 . . . . . . . . . . . .. . . . . . . . . . . . . AS4 Figure 2. Vijayanand et al. January 2007 [Page 19 ] INTERNET DRAFT BGP extensions for PCE inter-AS path January 2007 The Advertisements of each PCE are given below: PCE1: PCE-AS_TE Object AS Number : AS1 Router Address : Router ID of PCE1 Link TLV1 for link between ASBR1 and ASBR2 Link Type P2P Link ID : Hash( ip of asbr1 i/f, ip of asbr2 i/f) Inter-AS P2p Link sub-TLV: Local ASBR ASBR1, Remote ASBR ASBR2, Local AS AS1, Remote AS AS2. Maximum BW sub-TLV : Max bandwidth in the direction from ASBR1 to ASBR2. PCE2: PCE-AS_TE Object AS Number : AS2 Router Address : Router ID of PCE2 Link TLV (Link from ASBR1 to ASBR2) Link Type sub-TLV : Link Type P2P Link ID : Hash( ip of asbr2 i/f, ip of asbr1 i/f) Inter-AS P2p Link sub-TLV: Local ASBR ASBR2, Remote ASBR ASBR1,Local AS AS2, Remote AS AS1. Maximum BW sub-TLV : Max bandwidth in the direction from ASBR2 to ASBR1. Link TLV (Link from ASBR3 to ASBR5) Link Type sub-TLV : Link Type P2P Link ID : Hash( ip of asbr3 i/f, ip of asbr5 i/f) Inter-AS P2p Link sub-TLV: Local ASBR ASBR3, Remote ASBR ASBR5,Local AS AS2, Remote AS AS4. Maximum BW sub-TLV : Max bandwidth in the direction from ASBR3 to ASBR5. Link TLV (Link from ASBR4 to ASBR6) Link Type sub-TLV : Link Type P2P Link ID : Hash( ip of asbr4 i/f, ip of asbr6 i/f) Inter-AS P2p Link sub-TLV: Local ASBR ASBR4, Remote ASBR ASBR6,Local AS AS2, Remote AS AS3. Maximum BW sub-TLV : Max bandwidth in the direction from ASBR4 to ASBR6. Link TLV (TE-Tunnel: LSP1 from ASBR2 to ASBR3) Link Type sub-TLV : Link Type TE-Tunnel Link ID : Hash( ip of asbr2 i/f, LspId ) TE-Tunnel sub-TLV: Ingress ASBR asbr2, Egress ASBR asbr3, LSPID lsp1 Maximum BW sub-TLV : LSP Bandwidth Vijayanand et al. January 2007 [Page 20 ] INTERNET DRAFT BGP extensions for PCE inter-AS path January 2007 Link TLV (TE-Tunnel: LSP2 from ASBR2 to ASBR4) Link Type sub-TLV : Link Type TE-Tunnel Link ID : Hash( ip of asbr2 i/f, LspId ) TE-Tunnel sub-TLV: Ingress ASBR asbr2, Egress ASBR asbr4, LSPID lsp2 Maximum BW sub-TLV: LSP Bandwidth. PCE3: PCE-AS_TE Object AS Number : AS3 Router Address : Router ID of PCE3 Link TLV (Link from ASBR6 to ASBR4) Link Type sub-TLV : Link Type P2P Link ID : Hash( ip of asbr4 i/f, ip of asbr6 i/f) Inter-AS P2p Link sub-TLV: Local ASBR ASBR6,Remote ASBR ASBR4,Local AS AS3, Remote AS AS2. Maximum BW sub-TLV : Max bandwidth in the direction from ASBR6 to ASBR4. Link TLV (Link from ASBR7 to ASBR8) Link Type sub-TLV : Link Type P2P Link ID : Hash( ip of asbr7 i/f, ip of asbr8 i/f) Inter-AS P2p Link sub-TLV: Local ASBR ASBR7,Remote ASBR ASBR8,Local AS AS3, Remote AS AS4. Maximum BW sub-TLV : Max bandwidth in the direction from ASBR7 to ASBR8. Link TLV (TE-Tunnel : LSP3 from ASBR6 to ASBR7) Link Type sub-TLV : Link Type TE-Tunnel Link ID : Hash( ip of asbr6 i/f, ip of asbr7 i/f) TE-Tunnel sub-TLV: Ingress ASBR asbr6, Egress ASBR asbr7, LSPID lsp1 Maximum BW sub-TLV: LSP Bandwidth. PCE4: Opaque LSA PCE-AS_TE Object AS Number : AS4 Router Address : Router ID of PCE4 Link TLV (Link from ASBR3 to ASBR5) Link Type sub-TLV : Link Type P2P Link ID : Hash( ip of asbr3 i/f, ip of asbr5 i/f) Inter-AS P2p Link sub-TLV: Local ASBR ASBR5, Remote ASBR ASBR3,Local AS AS4, Remote AS AS2. Maximum BW sub-TLV : Max bandwidth in the direction from ASBR5 to ASBR3. Link TLV (Link from ASBR7 to ASBR8) Vijayanand et al. January 2007 [Page 21 ] INTERNET DRAFT BGP extensions for PCE inter-AS path January 2007 Link Type sub-TLV : Link Type P2P Link ID : Hash( ip of asbr7 i/f, ip of asbr8 i/f) Inter-AS P2p Link sub-TLV: Local ASBR ASBR8, Remote ASBR ASBR7, Local AS AS4, Remote AS AS3. Maximum BW sub-TLV : Max bandwidth in the direction from ASBR8 to ASBR7. Link TLV (TE-Tunnel: LSP4 from ASBR5 to ASBR9) Link Type sub-TLV : Link Type TE-Tunnel Link ID : Hash( ip of asbr5 i/f, LspId ) TE-Tunnel sub-TLV: Ingress ASBR asbr5, Egress ASBR asbr9, LSPID lsp1 Maximum BW sub-TLV: LSP Bandwidth. Link TLV (TE-Tunnel: LSP5 from ASBR8 to ASBR9) Link Type sub-TLV : Link Type TBD for TE-Tunnel Link ID : Hash( ip of asbr8 i/f, LspId ) TE-Tunnel sub-TLV: Ingress ASBR asbr8, Egress ASBR asbr9, LSPID lsp1 Maximum BW sub-TLV: LSP Bandwidth. In the above figure there are 4 ASes interconnected by point to point links between ASBRs. The ASBRs are also interconnected by TE- Tunnels within their AS. The significant contents of the PCE-AS-TLV object originated by the respective PCEs are shown above. Using the information in the PCE-AS-TE objects of all the PCEs, the PCEs learn about the topology shown above. The path computation for computing a TE path from a source in AS1 to destination in AS4 attached to ASBR9 would proceed as follows. The PCE in AS1 would know the topology and would compute the full path from ASBR1 to the destination attached to ASBR9.In the above topology the possible path could be: ASBR1,ASBR2,LSP1,ASBR3,ASBR5,LSP4,ASBR9. If there were no inter-ASBR TE-Tunnels or if they were only in some ASes and not in other ASes, or the destination was not directly attached to the egress of a TE-Tunnel, then it would be only possible to determine a set of possible AS paths and apply methods like those described in [BRPC]. In this topology PCE1 would compute two possible AS paths : AS1,AS2,AS4 and AS1,AS2,AS3,AS4( the destination can be found as attached to AS4 from the BGP route to the destination). It may use the first pre-determined AS path as input to the method described in [BRPC] and try to compute the path and set up the TE-LSP. If the path computation/setup fails along this path then it could use the second possible AS path to compute the path.In this case this method supplements the one described in [BRPC] Vijayanand et al. January 2007 [Page 22 ] INTERNET DRAFT BGP extensions for PCE inter-AS path January 2007 Without the method described in this document,it may not be possible to find out both the possible inter-AS paths in the above mentioned scenario.Normally,the BGP speaker on ASBR2 would receive two routes with different AS paths to the same destination from ASBR3 and ASBR4 and would choose one of the routes as the best route and propagate that to ASBR1. Hence, routers in AS1 may not be aware of the second possible AS path which could be used for setting up TE LSPs. Another possibility of loss of information could happen when along one of the AS paths an inter-AS link violates a TE constraint (for ex. It has less available bandwidth). In the above scenario BGP could relay the AS1,AS2,AS4 path to ASBR1 , but the link between AS2 and AS4(ASBR3-ASBR5) may not have enough bandwidth to satisfy the TE LSP. Hence the TE LSP setup would fail. When the method described in this document is followed, PCE1 would have information on the bandwidth availability on both the inter-AS TE links and when AS2-AS4 link does not have enough bandwidth the CSPF algorithm on PCE1 would automatically choose only the AS1,AS2,AS3,AS4 path and set up the TE LSP. 6. Interoperability Considerations BGP speakers which support this feature shall advertise the corresponding to the PCE-AS-TE object in the list of address families supported by the speaker. This can be advertised in the Capabilities Optional parameter[BGP-CAP] of the open message sent to the peer. A BGP speaker shall not advertise PCE information described in this document to a speaker which does not support the as advertised in its capabilities. 7. Acknowledgements The author is grateful to Thiruchitrambalamudayan and Thiruvengadamudayan for their constant support and motivation throughout. The valuable inputs received from Balaji and Chandrasekar are recalled with gratitude. 8. IANA considerations IANA is requested to assign a separate to be used in the MP-REACH-NLRI attribute for carrying the PCE-AS-TE object 9. Security Considerations This extension to BGP does not change the underlying security issues inherent in the existing BGP [Heffernan]. 10. Issue and Future considerations The Autonomous systems may be connected to each other using Vijayanand et al. January 2007 [Page 23 ] INTERNET DRAFT BGP extensions for PCE inter-AS path January 2007 multi-hop IP links. In those scenarios it is assumed that the link can be visualized as a single hop IP-link, by using IP-in-IP tunnels or MPLS tunnels between the ASBRs. The metrics of the various inter-AS TE links and the TE-Tunnels in the different ASes have to be comparable and have to be assigned in a standard/normalized way since they form as input to the CR-SPF algorithms in the PCE for computing inter-AS paths. 11. Authors' Addresses Vijayanand C HCL Technologies Ltd. No.184, NSK Salai, Vadapalani,Chennai -26 India. Phone : 91 44 23728366 ext:1357 Email : vijayc@hcl.in Somen Bhattacharya, Avici Systems. 101 Billerica Avenue N. Billerica, MA 01862 USA Phone : 1 978 964 2606 Email: somen@avici.com 12 References 12.1 Normative References [RFC-WORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4105] J.L. Le Roux, J.P. Vasseur,Boyle, " Requirements for Inter-Area MPLS Traffic Engineering", June 2005 [RFC4216] R. Zhang, J.P.Vasseur," MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) Requirements ", December 2005. [PCE-ARCH] Farrel, A., Vasseur, J.P., Ash, J., "Path Computation Element (PCE) Architecture ", draft-ietf-pce-architecture,work in progress. [PCE-DISCO-IGP] J.L. Le Roux, J.P. Vasseur, Yuichi Ikejir, Raymond Zhang,"IGP Protocol extensions for Path computation Element Discovery", draft-ietf-pce-disco-proto-igp, work in progress Vijayanand et al. January 2007 [Page 24 ] INTERNET DRAFT BGP extensions for PCE inter-AS path January 2007 [BRPC] JP. Vasseur, R. Zhang, N. Bitar, JL. Le Roux,"A Backward Recursive PCE-based Computation (BRPC) procedure to compute shortest inter-domain Traffic Engineering Label Switched Paths",draft-vasseur-pce-brpc-02,work in progress [PCE-DISCO-BGP] Vijayanand C, Somen Bhattacharya," BGP Protocol extensions for PCE Discovery across Autonomous systems ",draft-vijay-somen-pce-disco-proto-bgp, work in progress. [PD-PATH-COMP] J.P. Vasseur,A. Ayyangar,R. Zhang, " A Per-domain path computation method for establishing Inter-domain Traffic Engineering (TE) Label Switched Paths (LSPs)", August 2006 [BGP-CAP] R. Chandra, J. Scudder, "Capabilities advertisement with BGP-4", RFC3392,December 2002 [Heffernan] Heffernan, A.,"Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998. [GMPLS-ROUTING] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, October 2005. [GMPLS-SIG] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003. 12.2 Informative References [RFC3667] Bradner, S.,"IETF Rights in Contributions", BCP 78, RFC3667, February 2004. [PCE-DISC-REQ] J.L. Le Roux,"Requirements for Path Computation Element (PCE) Discovery", draft-ietf-pce-discovery-reqs-05.txt, work in progress. [FA-LSP] Kireeti Kompella, Yakov Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", rfc4206, October 2005. [PCE-DISCO-BGP] Vijayanand C, Somen Bhattacharya," BGP Protocol extensions for PCE Discovery across Autonomous systems ",draft-vijay-somen-pce-disco-proto-bgp, work in progress. Vijayanand et al. January 2007 [Page 25 ] INTERNET DRAFT BGP extensions for PCE inter-AS path January 2007 [PCE-ASBR-LOCATE] R. Zhang, M. Chen,"Locate ASBR in PCE", draft-zhang-pce-locate-asbr-00.txt,work in progress. [MP-BGP] T.Bates,Y.Rekhter,R.Chandra,D.Katz," Multiprotocol Extensions for BGP-4",RFC2858,June2000. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Vijayanand et al. January 2007 [Page 26 ]