B. A. Akyol Internet Draft Pluris Vach Kompella Vishal Sharma Jasmine Networks Document: draft-akyol-mpls-exp-ero-00.txt February 2001 Expires: August 2001 Expanded Explicit Route Object for RSVP-TE 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 document expands the Explicit Route Object (ERO) defined in [RSVP-TE]. The primary reason for the expansion of the ERO is to simplify the processing of abstract nodes and loose routes as well as to specify globally unique interface identifiers in case of unnumbered interfaces. Akyol draft-akyol-mpls-exp-ero-00.txt 1 Expanded Explicit Route Object for RSVP-TE February 2001 Table of Contents 1. Introduction and Motivation.....................................3 2. Definition of the Expanded Explicit Route Object................3 2.1 Expanded Explicit Route Object.................................4 2.1.1 IPV4_EERO_HOP................................................5 2.1.2 IPV6_EERO_HOP................................................6 2.1.3 IPV4_Abstract Node Hop (IPV4_AN_HOP).........................8 2.1.4 IPV6 Abstract Node HOP (IPV6_AN_HOP).........................9 2.1.5 IPV4 Loose Route Hop (IPV4_LR_HOP)..........................10 2.1.6 IPV6 Loose Route Hop (IPV6_LR_HOP)..........................11 3. Processing of the Expanded Explicit Route Object...............13 3.1 Explicitly routed LSP with no abstract nodes and no loose routes............................................................13 3.2 Explicitly routed LSP with abstract nodes and no loose routes.13 3.3 Explicitly routed LSP with loose routes and no abstract nodes.14 3.4 Explicitly routed LSP with loose routes and abstract nodes....14 4. Interoperability...............................................14 5. Conclusion.....................................................14 6. Security Considerations........................................15 7. References.....................................................16 8. Author's Addresses.............................................16 Akyol draft-akyol-mpls-exp-ero-00.txt 2 Expanded Explicit Route Object for RSVP-TE February 2001 Conventions used in this document 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]. 1. Introduction and Motivation This document expands on the explicit route object (ERO) used for establishing explicitly routed paths in an MPLS network as defined in [RSVP-TE]. This is necessary because of the following reasons: a. Uniqueness of interface identifiers for unnumbered interfaces. Interface identifiers as defined in [RSVP-UN] do not assure the uniqueness of interface identifiers in a network. Non-uniqueness of interface identifiers may cause some implementations of ERO processing to behave inconsistently. Specifically, ERO definition for unnumbered interfaces is context sensitive and dependent on the order of appearance in the ERO. For example, if the same interface identifier is repeated twice in the ERO consecutively, the desired behavior is unclear. b. Simplification of abstract node and loose-route processing. The proposed redefinitions described later in this text define separate abstract node and loose route objects. We believe that this will simplify the identification of an abstract or loose route while parsing the ERO. c. Different styles of specifying the ERO in different implementations. [RSVP-TE] gives the head-end LSR considerable leeway in specifying the ERO. For example, an LSR that is on the path can be specified by a router ID, an ingress (w.r.t. to the LSP) interface ID (usually an IP address), an egress interface ID or any combination of the above. This "flexibility" may cause LSP establishment and interoperability failures. 2. Definition of the Expanded Explicit Route Object This draft aims to make the ERO [RSVP-TE] more explicit. We define the following components of an Expanded Explicit Route Object (EERO): a. Each hop in the EERO will be specified by the following fields: Router ID as advertised by the interior gateway protocols (IGPs) with traffic engineering (TE) extensions; ingress interface identifier and unnumbered flag; egress interface identifier and unnumbered flag. For purposes of illustration, let us assign the markup identifier of to this component. b. An abstract node hop EERO component that defines one hop of an abstract node. This component is denoted by in the examples that follow. Akyol draft-akyol-mpls-exp-ero-00.txt 3 Expanded Explicit Route Object for RSVP-TE February 2001 c. A loose route hop EERO component that defines a loose hop in a loosely routed EERO segment. This component is denoted by in the examples that follow. 2.1 Expanded Explicit Route Object Expanded explicit routes are specified by the EXPANDED EXPLICIT_ROUTE object (EERO). An EERO uses the explicit route class 20 as defined in [RSVP-TE] and uses C_Type: Type 2, Expanded Explicit Route. The EERO has the following format: Class = 20, C_Type = 2 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // (Subobjects) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Subobjects The contents of an EXPANDED EXPLICIT_ROUTE object are a series of variable length data items called subobjects. The subobjects are defined in Sections 2.1.1 through 2.1.6. If a Path message contains multiple EEROs, the first one takes precedence and the rest MUST NOT be propagated. The EERO contains subobjects that are of variable length and have the form: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------//----------------+ | Type | Length | (Subobject contents) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------//----------------+ Type The Type indicates the type of contents of the subobject. The following values are currently defined: 0 Reserved 1 IPV4_EERO_HOP 2 IPV6_EERO_HOP 3 IPV4_Abstract Node Hop (IPV4_AN_HOP) 4 IPV6 Abstract Node Hop (IPV4_AN_HOP) 5 IPV4 Loose Route Hop (IPV4_LR_HOP) 6 IPV6 Loose Route Hop (IPV6_LR_HOP) Length Akyol draft-akyol-mpls-exp-ero-00.txt 4 Expanded Explicit Route Object for RSVP-TE February 2001 The Length contains the total length of the subobject in bytes including the Type and Length fields. The Length MUST be at least 4 bytes and MUST be a multiple of 4. 2.1.1 IPV4_EERO_HOP 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 |I|E| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Egress Interface Identifier (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ingress Interface Identifier (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 0x01 IPV4_EERO_HOP Length The Length indicates the total length of the sub- object. The length for this subobject is always 16 bytes. I Ingress Interface Identifier Unnumbered Flag. If this bit is set to 1, then the ingress interface is an unnumbered interface and the ingress interface identifier is a 32 bit identifier that is only locally significant to the router identified by Router ID. If this bit is not set, then the ingress identifier is an IPV4 address. E Egress Interface Identifier Unnumbered Flag. If this bit is set to 1, then the egress interface is an unnumbered interface and the egress interface identifier is a 32 bit identifier that is only locally significant to the router identified by Router ID. If this bit is not set, then the ingress identifier is an IPV4 address. Reserved Unused. MUST be zero. Ignored upon receipt. Akyol draft-akyol-mpls-exp-ero-00.txt 5 Expanded Explicit Route Object for RSVP-TE February 2001 Router ID The Router ID is an IPV4 address that MUST be the router ID IP address of the router that advertised the interfaces specified in this subobject as described in [ISIS-TE,OSPF-TE]. Ingress Interface Identifier The Ingress Interface Identifier is either an IPV4 address or a 32 bit interface index that is unique within the scope of the Router ID given in the subobject. Egress Interface Identifier The Egress Interface identifier is either an IPV4 address or a 32 bit interface index that is unique within the scope of the Router ID given in the subobject. 2.1.2 IPV6_EERO_HOP 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 |I|E| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID (16 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID (cont'd) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID (cont'd) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID (cont'd) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ingress Interface Identifier (16 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ingress Interface Identifier (cont'd) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ingress Interface Identifier (cont'd) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ingress Interface Identifier (cont'd) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Egress Interface Identifier (16 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Egress Interface Identifier (cont'd) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Egress Interface Identifier (cont'd) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Egress Interface Identifier (cont'd) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Akyol draft-akyol-mpls-exp-ero-00.txt 6 Expanded Explicit Route Object for RSVP-TE February 2001 Type 0x02 IPV6_EERO_HOP Length The Length field includes all fields of the subobject and is indicated in bytes. The length for this subobject is always 52 bytes. I Ingress Interface Identifier Unnumbered Flag. If this bit is set to 1, then the ingress interface is an unnumbered interface and the ingress interface identifier is a 32 bit identifier that is only locally significant to the router identified by Router ID. If this bit is not set, then the ingress identifier is an IPV6 address. E Egress Interface Identifier Unnumbered Flag. If this bit is set to 1, then the egress interface is an unnumbered interface and the egress interface identifier is a 32 bit identifier that is only locally significant to the router identified by Router ID. If this bit is not set, then the ingress identifier is an IPV6 address. Reserved Unused MUST be zero. Ignored upon receipt. Router ID The Router ID is an IPV6 address that MUST be the router ID IP address of the router that advertised the interfaces specified in this subobject as described in [ISIS-TE,OSPF-TE]. Ingress Interface Identifier The Ingress Interface Identifier is either an IPV6 address or a 32 bit interface index that is unique within the scope of the Router ID given in the subobject. If an interface index is given, the index MUST be given in the last 4 bytes of the IPV6 address field and the remaining 12 bytes MUST be set to 0. Egress Interface Identifier Akyol draft-akyol-mpls-exp-ero-00.txt 7 Expanded Explicit Route Object for RSVP-TE February 2001 The Egress Interface identifier is either an IPV4 address or a 32 bit interface index that is unique within the scope of the Router ID given in the subobject. If an interface index is given, the index MUST be given in the last 4 bytes of the IPV6 address field and the remaining 12 bytes MUST be set to 0. 2.1.3 IPV4_Abstract Node Hop (IPV4_AN_HOP) 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 |Prefix L. | Resvd | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPV4 Addr | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 0x03 IPV4_Abstract_Node_HOP Length The Length field includes all fields of the subobject and is indicated in bytes. The length for this subobject is always 8 bytes. Prefix Length The IPV4 prefix length in bits. This field is specified as an 8 bit field but is only meaningful when its value is less than or equal to 32. Reserved Reserved. MUST be zero. Ignored upon receipt. IPV4 Address An IPV4 address. This address MUST be treated as a prefix masked by prefix length given above. Bits exceeding the prefix length are ignored on receipt and SHOULD be set to zero on transmission [RSVP-TE]. Akyol draft-akyol-mpls-exp-ero-00.txt 8 Expanded Explicit Route Object for RSVP-TE February 2001 2.1.4 IPV6 Abstract Node HOP (IPV6_AN_HOP) 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 | Prefix L. | Resvd | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPV6 Addr (16 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPV6 Addr (cont'd) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPV6 Addr (cont'd) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPV6 Addr (cont'd) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 0x04 IPV6_Abstract_Node_HOP Length The Length field includes all fields of the subobject and is indicated in bytes. The length for this message is always 20 bytes. Prefix Length The IPV6 prefix length in bits. This field is specified as an 8 bit field but only values less than or equal to 128 are meaningful. Reserved Reserved. MUST be zero. Ignored upon receipt. IPV6 Address An IPV6 address. This address MUST be treated as a prefix masked by prefix length given above. Bits exceeding the prefix length are ignored on receipt and SHOULD be set to zero on transmission [RSVP-TE]. Akyol draft-akyol-mpls-exp-ero-00.txt 9 Expanded Explicit Route Object for RSVP-TE February 2001 2.1.5 IPV4 Loose Route Hop (IPV4_LR_HOP) 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 |I|E| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ingress Interface Identifier (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Egress Interface Identifier (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 0x05 IPV4_Loose_Route_HOP Length The Length field includes all fields of the subobject and is indicated in bytes. The length for this subobject is always 16 bytes. I Ingress Interface Identifier Unnumbered Flag. If this bit is set to 1, then the ingress interface is an unnumbered interface and the ingress interface identifier is a 32 bit identifier that is only locally significant to the router identified by Router ID. If this bit is not set, then the ingress identifier is an IPV4 address. E Egress Interface Identifier Unnumbered Flag. If this bit is set to 1, then the egress interface is an unnumbered interface and the egress interface identifier is a 32 bit identifier that is only locally significant to the router identified by Router ID. If this bit is not set, then the ingress identifier is an IPV4 address. Reserved Unused. MUST be zero. Ignored upon receipt. Akyol draft-akyol-mpls-exp-ero-00.txt 10 Expanded Explicit Route Object for RSVP-TE February 2001 Router ID The Router ID is an IPV4 address that MUST be the router ID IP address of the router that advertised the interfaces specified in this subobject as described in [ISIS-TE,OSPF-TE]. Ingress Interface Identifier The Ingress Interface Identifier is either an IPV4 address or a 32 bit interface index that is unique within the scope of the Router ID given in the subobject. For an IPV4_LR_HOP subobject, if this field is set to all zeros, then this value is ignored. Egress Interface Identifier The Egress Interface identifier is either an IPV4 address or a 32 bit interface index that is unique within the scope of the Router ID given in the subobject. For an IPV4_LR_HOP subobject, if this field is set to all zeros, then this value is ignored. 2.1.6 IPV6 Loose Route Hop (IPV6_LR_HOP) 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 |I|E| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID (16 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID (cont'd) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID (cont'd) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID (cont'd) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ingress Interface Identifier (16 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ingress Interface Identifier (cont'd) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ingress Interface Identifier (cont'd) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ingress Interface Identifier (cont'd) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Egress Interface Identifier (16 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Egress Interface Identifier (cont'd) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Akyol draft-akyol-mpls-exp-ero-00.txt 11 Expanded Explicit Route Object for RSVP-TE February 2001 | Egress Interface Identifier (cont'd) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Egress Interface Identifier (cont'd) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 0x06 IPV6_EERO_HOP Length The Length field includes all fields of the subobject and is indicated in bytes. The length for this subobject is always 52 bytes. I Ingress Interface Identifier Unnumbered Flag. If this bit is set to 1, then the ingress interface is an unnumbered interface and the ingress interface identifier is a 32 bit identifier that is only locally significant to the router identified by Router ID. If this bit is not set, then the ingress identifier is an IPV6 address. E Egress Interface Identifier Unnumbered Flag. If this bit is set to 1, then the egress interface is an unnumbered interface and the egress interface identifier is a 32 bit identifier that is only locally significant to the router identified by Router ID. If this bit is not set, then the ingress identifier is an IPV6 address. Reserved Unused. MUST be zero. Ignored upon receipt. Router ID The Router ID is an IPV6 address that MUST be the router ID IP address of the router that advertised the interfaces specified in this subobject as described in [ISIS-TE,OSPF-TE]. Ingress Interface Identifier The Ingress Interface Identifier is either an IPV6 address or a 32 bit interface index that is unique within the scope of the Router ID given in the subobject. If an interface index is given, the index MUST be given in the last 4 bytes of the IPV6 address Akyol draft-akyol-mpls-exp-ero-00.txt 12 Expanded Explicit Route Object for RSVP-TE February 2001 field and the remaining 12 bytes MUST be set to 0. For an IPV6_LR_HOP subobject, if this field is set to all zeros, then this value is ignored. Egress Interface Identifier The Egress Interface identifier is either an IPV6 address or a 32 bit interface index that is unique within the scope of the Router ID given in the subobject. If an interface index is given, the index MUST be given in the last 4 bytes of the IPV6 address field and the remaining 12 bytes MUST be set to 0. For an IPV6_LR_HOP subobject, if this field is set to all zeros, then this value is ignored. By utilizing the EERO components as given above, we address all of the concerns raised in Section 1. Processing of the EERO will be specified in the following section. 3. Processing of the Expanded Explicit Route Object There are four cases to consider when processing the EERO and they will be illustrated using the mark-up identifiers defined in Section 2: 3.1 Explicitly routed LSP with no abstract nodes and no loose routes. An EERO of this type is specified as: EERO := {, , .. , } The only check that needs to be performed during EERO processing at each hop is for the node to see if the top of the EERO stack points to itself and send the packet out of the interface pointed to by the . 3.2 Explicitly routed LSP with abstract nodes and no loose routes. An EERO of this type is specified as: EERO := {, , , .., ,.., , €, } Note that multiple abstract nodes may appear in an EERO, and they do not have to be contiguous. An abstract node can be deleted off the EERO element if and only if the next hop in the path is not part of the abstract node. An EERO may begin or end with an abstract node. Akyol draft-akyol-mpls-exp-ero-00.txt 13 Expanded Explicit Route Object for RSVP-TE February 2001 3.3 Explicitly routed LSP with loose routes and no abstract nodes. An EERO that includes loose hops and no abstract nodes is specified as follows: EERO := { , , , €, } While processing an EERO that contains loose hops, the loose hops within the loose segment are deleted as they are traversed. The loose segment is deleted only when the last loose hop in the segment is traversed. The path between the that precedes the that comes right after it is determined by consulting the IP forwarding table. In certain instances, it may be desirable to register a forwarding change indication associated with to be able to adapt to forwarding table changes rapidly. 3.4 Explicitly routed LSP with loose routes and abstract nodes. An abstract node can contain loose segments and vice versa. EEROs that contain both of these elements should be processed according to rules described in the preceding sections. 4. Interoperability Interoperability between different deployed versions of RSVP-TE software is our primary reason for defining an expanded ERO in place of redefining the existing ERO. The following rules assure interoperability between old and new versions of RSVP-TE software. a. An ingress LSR that supports both EERO and ERO MUST always generate an EERO when required. If the ingress LSR then gets an error message with error code equaling 14 (Unknown object C- Type), then the ingress LSR MUST retry the PATH message replacing the EERO with an equivalent ERO. b. Intermediary routers that support only the ERO MUST send an error message back to the ingress LSR with an error code 14 when a signaling message that contains an EERO is received. c. All routers that support EERO MUST also support the ERO. 5. Conclusion This Internet Draft presents a definition of the Expanded ERO object that was first defined in [RSVP-TE]. The expanded definition given here achieves our primary goal of both simplifying and clarifying explicit route processing in signaling protocol stack implementations while at the same time reducing the possibility of LSP routing failures. Akyol draft-akyol-mpls-exp-ero-00.txt 14 Expanded Explicit Route Object for RSVP-TE February 2001 6. Security Considerations This document does not add any new security issues other than the ones defined in [RSVP-TE]. Akyol draft-akyol-mpls-exp-ero-00.txt 15 Expanded Explicit Route Object for RSVP-TE February 2001 7. References [RSVP-TE] Awduche, D., Berger, L., Gan, D. H., Li, T., Srinivasan, V., and Swallow, G., "RSVP-TE: Extensions to RSVP for LSP Tunnels", draft-ietf-mpls-rsvp-lsp-tunnel-07.txt (work in progress) [RSVP-UN] Kompella K., Rekhter Y., " Signalling Unnumbered Links in RSVP-TE ", draft-ietf-mpls-rsvp-unnum-00.txt (Work in Progress) [ISIS-TE] Smit, H., and Li, T., "IS-IS extensions for Traffic Engineering", draft-ietf-isis-traffic-02.txt (work in progress) [OSPF-TE] Katz, D., and Yeung, D., "Traffic Engineering Extensions to OSPF", draft-katz-yeung-ospf-traffic-02.txt (work in progress) 8. Author's Addresses Bora Akyol Pluris 10455 Bandley Drive Cupertino, CA 95014 Email: akyol@akyol.org Phone: +1.408.861.3302 Vach Kompella Jasmine Networks, Inc. 3061 B, Zanker Road San Jose, CA 95134 Email: vkompella@jasminenetworks.com Phone: +1.408.895.5044 Vishal Sharma Jasmine Networks, Inc. 3061 B, Zanker Road San Jose, CA 95134 Email: vsharma@jasminenetworks.com Phone: +1.408.895.5030 Expiration This draft expires in August 2001. Akyol draft-akyol-mpls-exp-ero-00.txt 16