[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

                                                                 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 <EERO-HOP> to this component.
        b. An abstract node hop EERO component that defines one hop of an
           abstract node. This component is denoted by <AN-HOP> 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 <LOOSE-
           HOP> 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 := {<EERO-HOP>, <EERO-HOP>, .. , <EERO-HOP>}
     
         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
        <EERO-HOP>.
     
     3.2 Explicitly routed LSP with abstract nodes and no loose routes.
     
        An EERO of this type is specified as:
     
        EERO := {<EERO-HOP>, <EERO-HOP>, <AN-HOP>, .., <EERO-HOP>,..,  <AN-
        HOP>, €, <EERO-HOP>}
     
        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 := { <EERO-HOP>,  <LR-HOP>, <LR-HOP>,  €, <EERO-HOP>}
     
        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 <EERO-HOP> that precedes the  <LR-HOP> 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 <LR-HOP> 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
     

Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/