Internet DRAFT - draft-akyol-mpls-exp-ero
draft-akyol-mpls-exp-ero
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
