CCAMP Working group S. Dharanikota Internet Traffic Engineering Working Group Nayna Networks Internet Draft Document: S. Venkatachalam draft-dharanikota-interarea-mpls-te-ext-02.txt D. Papadimitriou Category: Expiration June 2002 Alcatel OSPF, IS-IS, RSVP, CR-LDP extensions to support inter-area traffic engineering using MPLS TE Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 except that the right to produce derivative works is not granted. This document is an Internet-Draft and is NOT offered in accordance with Section 10 of RFC2026, and the author does not provide the IETF with any rights other than to publish as an Internet-Draft 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. 1. Abstract In this draft, we propose the extensions required to the routing protocols, signaling protocols, and the MIB to support the idea of inter-area LSPs. A companion document [INTER_AREA_REQ] provides the architectural requirements for such a concept. This document also provides the signaling extensions to support the crankback as defined in the architecture document [INTER_AREA_REQ]. 2. Notation and Conventions used in this document ABR Area Border Router ASBR Autonomous System Border Router CR-LDP Constraint Based Routing LDP CSPF Constraint-based Shortest Path First ER Explicit Route ERO Explicit Route Object LSPCO LSP Constraints Object IGP Interior Gateway Protocol ISIS Intermediate System to Intermediate System ISP Internet Service Provider LDP Label Distribution Protocol LER Label Edge Router LSA Link State Attribute LSR Label Switch Router LSP Label Switched Path MIB Management Information Base MPLS Multi Protocol Label Switching OSPF Open Shortest Path First PDU Protocol Data Unit PLRO Primary LSP Route Object PRO Path Route Object PV Path Vector RSVP Resource Reservation Protocol TBD To Be Defined TE Traffic Engineering TLV Type Length Value 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 [RFC2119]. 3. Introduction The ISP's networks are divided into Autonomous Systems (ASs), where each AS is divided into IGP areas to allow the hiding and the aggregation of routing information. Although this concept of hierarchical routing by an IGP makes sense from the routing perspective, it is a bottleneck for traffic engineering as it hides the path taken by a packet to destinations in the other routing areas. Hence, from the TE perspective, requirements such as path selection and crankback need different architectural additions to the existing IGPs and signaling protocols for inter-area LSP setup. Traffic engineering practice currently involves the setup and use of Label Switched Paths (LSPs) as dedicated bandwidth pipes between two end points. LSPs can be setup across several routers, either through the use of manually specified routes, or routes that are computed. The routes can be computed offline through the use of a dedicated tool, or through the use of online constraint based routing using an IGP [IGP_REQ, RSVP_EXT]. From [TOOL_VS_RP] discussion, it is clear that traffic engineering can be implemented with the help of tools and routing protocol extensions, as initiated by [IGP_REQ]. This draft describes a framework for inter-area LSP setup. Inter-area routing is one of the main mechanisms used today to provide scalability within a IGP routing domain. Refer to RFC2329 for details regarding the usage of inter-area OSPF routing. In our solution, we propose to send across IGP areas, the summary routes containing TE route attributes, which will be used at both the ABRs, and the ASBRs in their TE path computation. Since an off-line TE tool cannot compute the complete explicit path from ASBR to ASBR (end to end within the AS domain) unless it knows the complete routing table of the AS, we expect to have loose path specification, which can be translated into explicit path in steps at the intermediate ABRs. The solutions we are providing in this draft are applicable to the destination networks inside the AS or outside the AS. For the sake of simplicity we consider the LSR performing the CSPF inside a given autonomous system. The companion document [INTER_AREA_REQ] presents the architectural requirements for such a solution. In this document, the extensions to provide such a solution of criteria-based inter-area routing are separated into routing protocol extensions, signaling protocol extensions and configuration extensions. In section 4, we present the OSPF and IS-IS extensions. The signaling extensions for RSVP and CR- LDP are presented in section 5. The configuration extensions for such architectural changes are presented in section 6. Security considerations, references and acknowledgements follow in sections 7, 8, and 9 respectively. 4. Routing protocol extensions 4.1 Intra-area requirements OSPF or ISIS implementation SHOULD support the [INTRA_TE], [ISIS_INTRA_TE] extensions to advertise and distribute the TE information of the interfaces of the area. In addition, [QOS_TE_EXT] may be supported to flood the bandwidth per class type of each interface. [INTRA_TE], [ISIS_INTRA_TE] defines the following TE attributes: - Traffic engineering metric - Maximum bandwidth - Maximum reservable bandwidth - Unreserved bandwidth - Resource class/color [QOS_TE_EXT] defines the unreserved bandwidth for different class types. Not all of the TE attributes specified in [INTRA_TE], [ISIS_INTRA_TE] and [QOS_TE_EXT] need to be supported - in fact a subset may be chosen that reflects the traffic engineering condition of the network and does not impose a burden on the storage and flooding of the TE information. Specific to OSPF: When a request for the setup of a constraint based LSP within the area is received, a CSPF computation will be performed on the TE resources of the area (as specified by the intra-area TE-LSAs) to determine the best path that satisfies the constraints. The constraints on the LSP can be one or more of the TE attributes flooded by OSPF in the intra- area TE LSA. Specific to ISIS: When a request for the setup of a constraint based LSP within the area is received, a CSPF computation will be performed on the TE resources of the area (as specified by the intra-area TE-LSAs) to determine the best path that satisfies the constraints of the LSP. The constraints on the LSP can be one or more of the TE attributes flooded by ISIS in the L1 extended IS reachability TE sub-TLVs. 4.2 Inter-area requirements The route computation process uses the inter-area TE summary information. - to determine if a path to the inter-area destination that satisfies the constraints does exist, and - to determine the ABR to reach the next area. TE attribute summarization is similar to the route summarization that is already a part of OSPF or ISIS. The TE attributes can be summarized through the use of a dijkstra based algorithm as described in section. The value of the TE summary attribute to a destination advertised by an ABR represents the TE resources of the best path available from the ABR to that destination based on that TE attribute alone. A separate route calculation is necessary to determine the summary value for each TE attribute that needs to be summarized. Since these route calculations are based on the intra-area TE attribute values, the set of TE attributes to be summarized should be a subset of the set of TE attributes supported inside the areas. In the general case of TE attribute summarization, any number of TE attributes such as bandwidth, delay to a destination can be summarized. However, since a large number of TE attributes to be summarized will result in an increase in processing required, the number of TE attributes to be summarized should be kept small. Specific to OSPF: The summarized TE attributes will be distributed inside the areas by the use of a new link state message (called TE summary LSA) as defined in [INTER_TE_OSPF]. The definitions for the various TE attributes in the TE summary LSA are also described in [INTER_TE_OSPF]. In addition to those TE attributes, the following three TLVs are proposed to be added in the TE summary LSA. Specific to ISIS: The summarized TE attributes will be distributed inside the areas by extending the IP reachability TLV in the L1 and L2 link state PDU to include TE sub-TLVs as described below. 4.3 Requirements for OSPF 4.3.1 Unreserved Bandwidth for CT1 to CT3 The unreserved bandwidth for class-types 1, 2 and 3 [QOS_CONST] to the destination are each individually described in a TLV. The units is bytes/second and the representation is IEEE floating point. The TLV types are 7, 8, and 9, respectively and the length is 32 octets each. 4.4. Requirements for ISIS 4.4.1 Traffic Engineering Extensions to the IP Reachability TLV This draft extends the IP Reachability TLV in the L1 and L2 link state PDUs to allow the representation of TE information in the form of TE sub-TLVs. Each TE sub-TLV in the IP Reachability TLV carries the type and value of a traffic engineering attribute to the remote destination. An L2 link state PDU containing the IP reachability TLV with the TE extensions will be originated by an L1/L2 router and flooded throughout the L2 domain. This PDU will contain IP reachability TLV with the TE sub-TLVs for each reachable address in the connected areas. The value for each TE attribute will have been computed through the use of a dijkstra based algorithm as detailed in the next section. (This is the 'up' part of the redistribution as detailed in [ISIS_TE]). An L1 link state PDU containing the IP reachability TLV with the TE extensions will be originated by an L1/L2 router and flooded throughout its connected areas. This PDU will contain IP reachability TLV with the TE sub-TLVs for each reachable address in a remote area. (This is the 'down' part of the redistribution as detailed in [ISIS_TE]). 4.4.2 Format of the IP reachability TLV with TE Sub-TLVs The extended IP reachability TLV as described in [ISIS_TE] with TYPE = 135 is further extended with the addition of the TE sub-TLVs describing the traffic engineering attributes to the destination network. Hence the IP reachability TLV has a structure as described in [ISIS_TE], followed by zero or more TE sub-TLVs, each of which is of the form: No. of Octets +---------------------------+ | CODE | 1 +---------------------------+ | LENGTH | 1 +---------------------------+ | VALUE | LENGTH +---------------------------+ 4.4.3 The Traffic Engineering Sub-TLVs The following traffic engineering attributes are defined: Sub-TLV type Length (octets) Name 3 4 Resource Class/Color 9 4 Maximum Bandwidth 10 4 Reservable Bandwidth 11 32 Unreserved Bandwidth 18 3 TE Default Metric TBD 4 Delay TBD 32 Unreserved Bandwidth for CT1 TBD 32 Unreserved Bandwidth for CT2 TBD 32 Unreserved Bandwidth for CT3 Most of these traffic engineering attributes have sizes and types the same as in [ISIS_TE]. Note that new traffic engineering attributes and sub-TLVs to represent them may be defined in the future. The TE attributes are described below. 4.4.3.1 Resource Class/Color The resource class or color of the destination network is a combination of the colors for the various paths to the network. The sub-TLV type of the resource class/color attribute is 3, and the length is 4 octets. 4.4.3.2 Maximum Bandwidth The maximum bandwidth to the destination is described in bytes/second as an IEEE floating point number. The sub-TLV type is 9, and the length is 4 octets. 4.4.3.3 Reservable Bandwidth The reservable bandwidth to the destination is described in bytes/second as an IEEE floating point number. The sub-TLV type is 10, and the length is 4 octets. 4.4.3.4 Unreserved Bandwidth The unreserved bandwidth to the destination is described in bytes/second as an IEEE floating point number. The sub-TLV type is 11, and the length is 4 octets. 4.4.3.5 Traffic Engineering Metric The traffic engineering metric represents the traffic engineering cost of reaching the destination network from the advertising L2 router. The sub-TLV type is 18, and the length of this attribute is 3 octets. 4.4.3.6 Delay The delay attribute is the delay cost to reach the destination network in milliseconds, represented as an unsigned (4-byte) long integer. The TLV-type is TBD, and the length is 4 octets. 4.4.3.7 Unreserved Bandwidth for CT1 to CT3 The unreserved bandwidth for class-types 1, 2 and 3 [QOS_CONST] to the destination are each individually described in a sub-TLV. The units is bytes/second and the representation is IEEE floating point. The sub- TLV types are TBD, and the length is 4 octets. 4.5 Summarization of Traffic Engineering Attributes The traffic engineering metric is an additive metric similar to the OSPF/ISIS metrics, but need not be the same. The traffic engineering and metric advertised by the router for the given summary destination will have been computed in a manner similar to the dijkstra computation for the OSPF/ISIS metric. The delay is an additive metric. The value of the delay attribute for a summary destination will have been determined through a dijkstra computation based on the delay. The maximum bandwidth to the summary destination is the largest of all path-capacities, each associated with a possible path to the destination. The path-capacity is the smallest link capacity of all the links in the path. Hence, the maximum bandwidth is the maximum amount of traffic that can be sent to that destination, when there is no other traffic on the links. The unreserved bandwidth to the summary destination is the largest of all path-unreserved bandwidths, each associated with a possible path to the destination. The path-unreserved bandwidth is the smallest unreserved bandwidth of all the links in the path. Hence, the unreserved bandwidth is the maximum amount of traffic that can currently be sent to that destination, the other traffic on the links being steady. The unreserved bandwidth for Class-Types 1, 2, and 3 [QOS_CONST] will be computed similarly. The value of the color attribute to the summary destination is some combination of the path-colors, each associated with a possible path to the destination. The path-color is a combination of the colors of the links in the path. This combination can be a "logical and" of the colors, or a concatenation. 5. Signaling Extensions The signaling protocol requirements for the setup of the inter-area LSP are (as mentioned in [INTE_AREA_REQ]): 1. Signaling SHOULD be extended to carry the LSP constraints as an n-tuple of (TE Attribute 1, ..., TE Attribute N) which will be used to trigger CSPF as intermediate ABRs. 2. Signaling SHOULD trigger IGP computation for the explicit route in an area at the transit ABRs. 3. The intermediate ABRs SHOULD know the difference between the primary and the backup LSPs. This enables the signaling component to distinguish between the paths taken by the primary LSP during the computation of the backup LSP. 4. The same mechanisms used for the primary LSP setup SHOULD be used for the backup LSP setup also. 5. Crankback in an area SHOULD always be performed from the starting ABR of that LSP section. If the path is not available send the information one area back and try to perform the computation. 5.1 RSVP extensions In this section we describe extensions to RSVP for the support of Inter-Area LSP setup as described in [INTER_AREA_REQ]. These extensions are in addition to the extensions to RSVP as defined in [RSVP_EXT] and includes attributes from [QOS_TE_EXT] [TE_FRAMEWORK] as sub-objects. Three new objects are introduced as follows: - <LSP CONSTRAINTS> object (from now on is also abbreviated as LSPCO) introduced to carry the constraints that the inter-area LSP is required to satisfy. - <PRIMARY LSP ROUTE> object (from now on abbreviated as PLRO) to carry the path followed by the primary LSP in the PATH message. In the following sections we also demonstrate different uses of ERO (EXPLICIT ROUTE OBJECT) and RRO (RECORD ROUTE OBJECT) from the [RSVP_EXT] draft. Note that constraint-related objects such as <CLASSTYPE> as mentioned in [QOS_TE_EXT] can be sub-objects in the LSPCO. The following table illustrates the objects discussed that are relevant for this draft. Object type Message Importance -------------------------------------------------------------------- <LSP CONSTRAINTS> Path Mandatory <PRIAMRY LSP ROUTE> Path Mandatory <DIFFSERV><CLASSTYPE> Path Optional <EXPLICIT ROUTE> Path Optional <RECORD ROUTE> Path, Resv Optional but recommended 5.1.1 PATH and RESV message format changes The format of the Path message is changed as follows: <Path Message> ::= <Common Header> [<INTEGRITY>] <SESSION> <RSVP_HOP> <TIME_VALUES> [<EXPLICIT_ROUTE>] <LABEL_REQUEST> [<SESSION_ATTRIBUTE>] [<LSP CONSTRAINTS>] [<PRIMARY LSP ROUTE>] [<POLICY_DATA> ... ] [<sender descriptor>] <sender descriptor> ::= <SENDER_TEMPLATE> [<SENDER_TSPEC>] [<ADSPEC>] [<RECORD_ROUTE>] 5.1.2 Handling of the new objects The following are the message formats for the new objects that are introduced in this document. LSP CONSTRAINTS Object (LSPCO): 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 (12 bits) | C-Number (TBD)| Reserved | | | (8 bits) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Constraint TLV for 1st TE Attribute | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | | Constraint TLV for nth TE Attribute | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ C-Number: To be defined by IANA C-Type: 1 Constraints: The LSP constraints for each attribute is carried in the form of a constraint TLV, as 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 of TE attribute | Length of TE attribute | | (16 bits) | (16 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Constraint value of TE attribute | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The LSP constraint values can be defined for the following TE attributes, similar to the TE attributes defined for the routing protocols. Type Length TE attribute 1 4 Resource Class/Color 2 4 Maximum Bandwidth 3 4 Reservable Bandwidth 4 32 Unreserved Bandwidth 5 3 TE Default Metric 6 4 Delay 7 32 Unreserved Bandwidth for CT1 8 32 Unreserved Bandwidth for CT2 9 32 Unreserved Bandwidth for CT3 PRIMARY LSP ROUTE Object (PLRO): 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 | C-Number = TBD| C-Type = 0 for IPv4 | | (16 bits) | (8 bits) | (8 bits) 1 for IPv6 | | | | 2 for unavail| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Address 1 (V4 or V6) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | | IP Address N (V4 or V6) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ C-Number: To be defined by IANA C-Type: 1 for the IPV4 address 2 for the IPV6 address 3 for the unavailability of the objects. The LSPCO can be used very effectively in conjunction with the ERO and RRO objects. It is possible that the ERO and RRO options are enabled to specify a preferred path and to know the path taken by the LSP respectively. The following list of cases we will illustrate the handling of the LSPCO, and PLRO objects in conjunction with the ERO and RRO objects. Case 1: LSPCO + ERO with strict route option: If the LSP setup fails at a strict node along the path, then a PATHErr message is sent back to the head LER with error code "LSP Constraint Failure". Case 2: LSPCO + ERO with loose source route option: If the LSP setup fails at a loose node along the path, then a different path to the node may be tried - a PATHErr is returned to the previous ABR to recompute a path Case 3: With or without PLRO: When PLRO is present we can avoid overlapping segments between the primary and the backup LSPs. 5.1.3 Error conditions The following are the error conditions 1 LSP Constraint Failure (with the ABRs traversed) 2 Unknown Constraint 3 Unknown Object 5.2 CR-LDP extensions In this section we describe extensions to CR-LDP for the support of Inter-Area LSP setup as described in [INTER_AREA_REQ]. These extensions are in addition to the extensions to CR-LDP as defined in [CR_LDP] and includes the attributes from [QOS_TE_EXT], [TE_FRAMEWORK] as sub-objects. Three new objects are introduced as follows: - <LSP CRITERIA TLV> (LSPC-TLV) is used to carry the constraints that the inter-area LSP is required to satisfy. - <PRIMARY LSP ROUTE TLV> (PLR-TLV) is used to carry the path followed by the primary LSP in the Label Request message. Note that constraint-related TLVs such as <CLASSTYPE> as mentioned in [QOS_TE_EXT] can be sub-TLVs in the LSPCO. The following table illustrates the objects discussed that are relevant for this draft. Object type Message Importance -------------------------------------------------------------------- <LSP CONSTRAINTS TLV> Label Request Mandatory <PRIAMRY LSP ROUTE TLV> Label Request Mandatory <DIFFSERV TLV><CLASSTYPE TLV> Label Request Optional <EXPLICIT ROUTE TLV> Label Request Optional <PATH VECTOR TLV> Label Request/Mapping Optional(recommended) 5.2.1 Label Request and Label Mapping messages Encoding The encoding for the CR-LDP Label Request message is extended as follows, to optionally include the LSP Constraints TLV (which and Primary LSP Route TLV: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Label Request (0x0401) | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ER-LSP TLV (CR-LDP Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PATH VECTOR TLV (Optional but Recommended) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSP CONSTRAINTS TLV (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PRIAMRY LSP ROUTE TLV (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Other CR-LDP TLVs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.2.2 Handling of the new objects The following are the message formats for the new objects that are introduced in this document. The LSP CONSTRAINTS TLV has the following 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| LSPC TLV | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TE CONSTRAINT sub-TLVs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Notice that the U and F bits are set to 0 to abort the connection setup in case any LSP does not know how to use these mechanisms. The TE CONSTRAINT sub-TLVs follow the 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| TE attribute Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Constraint value of TE attribute | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The sub TLV carries the constraint value of a TE attribute/metric. The constraints that can be defined are the same as in section 5.1.2 for RSVP's PATH message. Also note that the U and F flags are set to 0. PRIMARY LSP ROUTE TLV 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|PRIMARY LSP ROUTE TLV | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPV4/ IPV6 HOP 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPV4/ IPV6 HOP N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This TLV contains the path taken by the Primary LSP. It can have IPV4 or IPV6 address hops taken by this path. The LSPC TLV can be used very effectively in conjunction with the Explicit Route (ER) TLV and Path Vector (PV) TLV. It is possible that the ER TLV and PV TLV options are enabled to specify preferred path and to know the path taken by the LSP respectively. The following list of cases we will illustrate the handling of the LSPC, and PLRO TLVs in conjunction with the ER TLV and PR TLV. Case 1: LSPC + ER TLV with strict route option: If the LSP setup fails at a strict node along the path, then an LDP Notification message is sent back to the head LER with error code "LSP Constraint Failure". Case 2: LSPC + ER TLV with loose source route option: If the LSP setup fails at a loose node along the path, then a different path to the node may be tried - an LDP Notification message is returned to the previous ABR to recompute a path Case 3: With or without PL TLV: When PL-TLV is present we can avoid overlapping segments between the primary and the secondary LSPs. 5.2.3 Status codes for the inter-area LSP setup In the procedures described above, certain errors must be reported. The following values are defined for the Status Code field: Status Code E Status Data LSP Constraint Failure 0 TBD Unknown Criteria 0 TBD Unknown TLV 0 TBD Note: The criteria failures should always inform the ABR path taken for the current reservation. 6. MIB requirements (TBD) The configuration requirements for such architecture can be divided into: - Routing configuration, such as constraint filtering - LSP Setup configuration, such as constraints - Signaling configuration, such as crankback in-progress notification required etc. These configuration information will be further elaborated in the later versions of this draft. 7. Security Considerations (TBD) 8. Acknowledgements The authors acknowledge Darek Skalecki, Ramana Gollamudi and Rao Vadlamani for their insightful comments. 9. References [RFC2026] S. Bradner, "The Internet Standards Process," Revision 3, BCP 9, RFC 2026. [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels," BCP 14, RFC2119. [IGP_REQ] T. Li, G. Swallow, D. Awduche, "IGP Requirements for Traffic Engineering with MPLS," <draft-li-mpls-igp-00.txt> [CRANKBACK] A. Iwata, et. al., "Crankback Routing Extensions for CR-LDP," <draft-iwata-mpls-crankback-01.txt> [TOOL_VS_RP] "Internet Traffic Engineering working group mailing list discussion on centralized tool based TE versus constraint- based routing protocol extensions," ftp://ftpext.eng.uu.net/tewg [QOS_CONST] F. Le Faucheur et al., "Requirements for support of DiffServ-aware MPLS Traffic Engineering," <draft-ietf-diff-te-reqts-01.txt> [QOS_TE_EXT] F. Le Faucheur et al., "Protocol extensions for support of DiffServ-aware MPLS Traffic Engineering," <draft-lefaucheur-diff-te-proto-00.txt> [INTRA_AREA] D. Katz, D. Yeung, K. Kompella, "Traffic Engineering Extensions to OSPF," <draft-katz-yeung-ospf-traffic-06.txt> [INTER_AREA_REQ] S. Venkatachalam, S. Dharanikota, D. Papadimitriou, "A frame work for the LSP setup across IGP areas for MPLS traffic engineering," <draft-venkatachalam-interarea-mpls-te-02.txt> [TE_FRAMEWORK] D. O. Awduche, et al., "A Framework for internet Traffic Engineering," <draft-ietf-tewg-framework-02.txt> [OSPF_RFC] J. Moy, "OSPF Version 2," RFC 2328. [OPAQUE_LSA] R. Coltun, "The OSPF Opaque LSA Option," RFC 2370. [RSVP_EXT] D. Awduche et al., "Extensions to RSVP for LSP Tunnels," <draft-ietf-mpls-rsvp-lsp-tunnel-09.txt> [INTER_TE_OSPF] S. Venkatachalam, and B. Abarbanel, "OSPF Extensions to Support Inter-Area Traffic Engineering," <draft- venkatachalam-ospf-traffic-02.txt > [ISIS_ISO] "Intermediate System to Intermediate System Intra- Domain Routeing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473)," ISO DP 10589, February 1990. [ISIS_IETF] R. Callon, "Use of OSI IS-IS for Routing in TCP/IP and Dual Environments," RFC 1195. [ISIS_TE] H. Smit, and T. Li, "IS-IS Extensions for Traffic Engineering," <draft-ietf-isis-traffic-04.txt> 9. Author's Addresses Sudheer Dharanikota Nayna Networks 481 Sycamore Drive Milpitas, CA 95035 Email: sudheer@nayna.com Senthil Venkatachalam Alcatel 15036 Conference Center Drive Chantilly, VA 20151 Phone: (703)679-6435 Email: Senthil.Venkatachalam@alcatel.com, senthil_v@lycos.com Papadimitriou Dimitri Alcatel \373 IPO NSG-NA Francis Wellesplein 1, B-2018 Antwerpen, Belgium Phone: +32 3 240-8491 Email: dimitri.papadimitriou@alcatel.be