draft-ietf-ccamp-rsvp-te-exclude-route-05.txt   draft-ietf-ccamp-rsvp-te-exclude-route-06.txt 
Network Working Group CY. Lee Network Working Group CY. Lee
Internet-Draft A. Farrel (Old Dog Consulting) Internet-Draft A. Farrel (Old Dog Consulting)
Expires: February 26, 2006 S. De Cnodder (Alcatel) Intended Status: Standards Track S. De Cnodder (Alcatel)
August 26, 2005 Updates: RFC3209 and RFC3473 November 2006
Exclude Routes - Extension to RSVP-TE Exclude Routes - Extension to RSVP-TE
draft-ietf-ccamp-rsvp-te-exclude-route-05.txt draft-ietf-ccamp-rsvp-te-exclude-route-06.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 26, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract Abstract
The RSVP-TE specification, "RSVP-TE: Extensions to RSVP for LSP The RSVP-TE specification, "RSVP-TE: Extensions to RSVP for LSP
Tunnels" (RFC 3209) and GMPLS extensions to RSVP-TE, "Generalized Tunnels" (RFC 3209) and GMPLS extensions to RSVP-TE, "Generalized
Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions" (RFC 3473) allow Protocol-Traffic Engineering (RSVP-TE) Extensions" (RFC 3473) allow
abstract nodes and resources to be explicitly included in a path abstract nodes and resources to be explicitly included in a path
setup, but not to be explicitly excluded. setup, but not to be explicitly excluded.
In some networks where precise explicit paths are not computed at the In some networks where precise explicit paths are not computed at the
skipping to change at page 3, line 7 skipping to change at page 2, line 13
path setup using RSVP-TE. path setup using RSVP-TE.
Requirements notation Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Scope of Exclude Routes . . . . . . . . . . . . . . . . . 5 1.1 Scope of Exclude Routes . . . . . . . . . . . . . . . . . 4
1.2 Relationship to MPLS TE MIB . . . . . . . . . . . . . . . 6 1.2 Relationship to MPLS TE MIB . . . . . . . . . . . . . . . 5
2. Shared Risk Link Groups . . . . . . . . . . . . . . . . . . . 6 2. Shared Risk Link Groups . . . . . . . . . . . . . . . . . . . 6
2.1 SRLG ERO Subobject . . . . . . . . . . . . . . . . . . . . 6 2.1 SRLG Subobject . . . . . . . . . . . . . . . . . . . . . . 6
3. Exclude Route List . . . . . . . . . . . . . . . . . . . . . . 7 3. Exclude Route List . . . . . . . . . . . . . . . . . . . . . . 7
3.1 Exclude Route Object (XRO) . . . . . . . . . . . . . . . . 7 3.1 Exclude Route Object (XRO) . . . . . . . . . . . . . . . . 7
3.1.1 IPv4 prefix Subobject . . . . . . . . . . . . . . . . 9 3.1.1 IPv4 prefix Subobject . . . . . . . . . . . . . . . . 8
3.1.2 IPv6 Prefix Subobject . . . . . . . . . . . . . . . . 10 3.1.2 IPv6 Prefix Subobject . . . . . . . . . . . . . . . . 9
3.1.3 Unnumbered Interface ID Subobject . . . . . . . . . . 11 3.1.3 Unnumbered Interface ID Subobject . . . . . . . . . . 10
3.1.4 Autonomous System Number Subobject . . . . . . . . . . 12 3.1.4 Autonomous System Number Subobject . . . . . . . . . . 10
3.1.5 SRLG Subobject . . . . . . . . . . . . . . . . . . . . 12 3.1.5 SRLG Subobject . . . . . . . . . . . . . . . . . . . . 11
3.2 Processing Rules for the Exclude Route Object (XRO) . . . 12 3.2 Processing Rules for the Exclude Route Object (XRO) . . . 11
4. Explicit Exclusion Route . . . . . . . . . . . . . . . . . . . 14 4. Explicit Exclusion Route . . . . . . . . . . . . . . . . . . . 13
4.1 Explicit Exclusion Route Subobject (EXRS) . . . . . . . . 14 4.1 Explicit Exclusion Route Subobject (EXRS) . . . . . . . . 13
4.2 Processing Rules for the Explicit Exclusion Route 6 4.2 Processing Rules for the Explicit Exclusion Route
Subobject (EXRS) . . . . . . . . . . . . . . . . . . . . . 17 Subobject (EXRS) . . . . . . . . . . . . . . . . . . . . . 15
5. Processing of XRO together with EXRS . . . . . . . . . . . . . 16 5. Processing of XRO together with EXRS . . . . . . . . . . . . . 16
6. Minimum compliance . . . . . . . . . . . . . . . . . . . . . . 17 6. Minimum compliance . . . . . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
8.1 New RSVP-TE Class Numbers . . . . . . . . . . . . . . . . 18 8.1 New ERO Subobject Type . . . . . . . . . . . . . . . . . . 17
8.2 New ERO Subobject Type . . . . . . . . . . . . . . . . . . 18 8.2 New RSVP-TE Class Numbers . . . . . . . . . . . . . . . . 18
8.3 New ERO and XRO Subobject Type . . . . . . . . . . . . . . 18 8.3 New Error Codes . . . . . . . . . . . . . . . . . . . . . 18
8.4 New Error Codes . . . . . . . . . . . . . . . . . . . . . 18 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1 Normative References . . . . . . . . . . . . . . . . . . . 19 10.1 Normative References . . . . . . . . . . . . . . . . . . . 19
10.2 Informational References . . . . . . . . . . . . . . . . . 19 10.2 Informational References . . . . . . . . . . . . . . . . . 19
11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 20 11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 20
Apendix A. Aplications . . . . . . . . . . . . . . . . . . . . . . 21 Apendix A. Aplications . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
The RSVP-TE specification [RFC3209] and GMPLS extensions [RFC3473] The RSVP-TE specification [RFC3209] and GMPLS extensions [RFC3473]
allow abstract nodes and resources to be explicitly included in a allow abstract nodes and resources to be explicitly included in a
path setup, using the Explicit Route Object (ERO). path setup, using the Explicit Route Object (ERO).
In some systems it may be useful to specify and signal abstract nodes In some systems it may be useful to specify and signal abstract nodes
and resources that are to be explicitly excluded from routes. This and resources that are to be explicitly excluded from routes. This
may be because loose hops or abstract nodes need to be prevented from may be because loose hops or abstract nodes need to be prevented from
selecting a route through a specific resource. This is a special selecting a route through a specific resource. This is a special
case of distributed path calculation in the network. case of distributed path calculation in the network.
For example, route exclusion could be used in the case where two
non-overlapping Label Switched Paths (LSPs) are required. In this
case, one option might be to set up one path and collect its route
using route recording, and then to exclude the routers on that first
path from the setup for the second path. Another option might be to
set up two parallel backbones, dual home the provider edge (PE)
routers to both backbones, and then exclude the local router on
backbone A the first time that you set up an LSP (to a particular
distant PE), and exclude the local router on backbone B the second
time that you set up an LSP.
Two types of exclusions are required: Two types of exclusions are required:
1. Exclusion of certain abstract nodes or resources on the whole 1. Exclusion of certain abstract nodes or resources on the whole
path. This set of abstract nodes is referred to as the Exclude path. This set of abstract nodes is referred to as the Exclude
Route list. Route list.
2. Exclusion of certain abstract nodes or resources between a 2. Exclusion of certain abstract nodes or resources between a
specific pair of abstract nodes present in an ERO. Such specific specific pair of abstract nodes present in an ERO. Such specific
exclusions are referred to as Explicit Exclusion Route. exclusions are referred to as Explicit Exclusion Route.
skipping to change at page 4, line 38 skipping to change at page 3, line 49
object and a new ERO subobject are introduced respectively. object and a new ERO subobject are introduced respectively.
- A new RSVP-TE object is introduced to convey the Exclude Route - A new RSVP-TE object is introduced to convey the Exclude Route
list. This object is the Exclude Route Object (XRO). list. This object is the Exclude Route Object (XRO).
- The second type of exclusion is achieved through a modification to - The second type of exclusion is achieved through a modification to
the existing ERO. A new ERO subobject type the Explicit Exclusion the existing ERO. A new ERO subobject type the Explicit Exclusion
Route Subobject (EXRS) is introduced to indicate an exclusion Route Subobject (EXRS) is introduced to indicate an exclusion
between a pair of included abstract nodes. between a pair of included abstract nodes.
The knowledge of SRLGs, as defined in [INTERAS-REQ], may be used to The knowledge of SRLGs, as defined in [RFC4216], may be used to
compute diverse paths that can be used for protection. In systems compute diverse paths that can be used for protection. In systems
where it is useful to signal exclusions, it may be useful to signal where it is useful to signal exclusions, it may be useful to signal
SRLGs to indicate groups of resources that should be excluded on the SRLGs to indicate groups of resources that should be excluded on the
whole path or between two abstract nodes specified in an explicit whole path or between two abstract nodes specified in an explicit
path. path.
This document introduces an ERO subobject to indicate an SRLG to be This document introduces a subobject to indicate an SRLG to be
signaled in either of the two exclusion methods described above and signaled in either of the two exclusion methods described above. This
this document does not assume or preclude any other usage for this document does not assume or preclude any other usage for this
subobject. This subobject might also be appropriate for use within subobject. This subobject might also be appropriate for use within an
Explicit Routes or Record Routes, but this is outside the scope of Explicit Route object (ERO) or Record Route object (RRO), but this is
this document. outside the scope of this document.
1.1 Scope of Exclude Routes 1.1 Scope of Exclude Routes
This document does not preclude a route exclusion from listing This document does not preclude a route exclusion from listing
arbitrary nodes or network elements to avoid. The intent is, arbitrary nodes or network elements to avoid. The intent is,
however, to indicate only the minimal number of subobjects to be however, to indicate only the minimal number of subobjects to be
avoided. For instance it may be necessary to signal only the SRLGs explicitly avoided. For instance it may be necessary to signal only
(or Shared Risk Groups) to avoid. the SRLGs (or Shared Risk Groups) to avoid. That is, the route
exclusion is not intended to define the actual route by listing all
of the choices to exclude at each hop, but rather to constrain the
normal route selection process where loose hops or abstract nodes
are to be expanded by listing certain elements to be avoided.
It is envisaged that most of the conventional inclusion subobjects It is envisaged that most of the conventional inclusion subobjects
are specified in the signaled ERO only for the area where they are are specified in the signaled ERO only for the area where they are
pertinent. The number of subobjects to be avoided, specified in the pertinent. The number of subobjects to be avoided, specified in the
signaled XRO may be constant throughout the whole path setup, or the signaled XRO may be constant throughout the whole path setup, or the
subobjects to be avoided may be removed from the XRO as they become subobjects to be avoided may be removed from the XRO as they become
irrelevant in the subsequent hops of the path setup. irrelevant in the subsequent hops of the path setup.
For example, consider an LSP that traverses multiple computation For example, consider an LSP that traverses multiple computation
domains. A computation domain may be an area in the administrative domains. A computation domain may be an area in the administrative
skipping to change at page 6, line 32 skipping to change at page 6, line 7
configure explicit routes for use on specific LSPs. This configure explicit routes for use on specific LSPs. This
configuration allows the exclusion of certain resources. configuration allows the exclusion of certain resources.
In systems where the full explicit path is not computed at the In systems where the full explicit path is not computed at the
ingress (or at a path computation site for use at the ingress) it may ingress (or at a path computation site for use at the ingress) it may
be necessary to signal those exclusions. This document offers a be necessary to signal those exclusions. This document offers a
means of doing this signaling. means of doing this signaling.
2. Shared Risk Link Groups 2. Shared Risk Link Groups
The identifier of a SRLG is defined as a 32 bit quantity in [GMPLS- The identifier of a SRLG is defined as a 32 bit quantity in
RTG]. An SRLG ERO subobject is introduced such that it can be used [RFC4202]. An SRLG subobject is introduced such that it can be used
in the exclusion methods as described in the following sections. in the exclusion methods as described in the following sections.
This document does not assume or preclude any other usage for this This document does not assume or preclude any other usage for this
subobject. This subobject might also be appropriate for use within subobject. This subobject might also be appropriate for use within
Explicit Routes or Record Routes, but this is outside the scope of Explicit Route object (ERO) or Record Route object (RRO), but this is
this document. outside the scope of this document.
2.1 SRLG ERO Subobject 2.1 SRLG Subobject
The format of the ERO and its subobjects are defined in [RFC3209]. The new SRLG subobject is defined by this document as follows. Its
The new SRLG subobject is defined by this document as follows. format is modeled on the ERO subobjects defined in [RFC3209].
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | SRLG Id (4 bytes) | |L| Type | Length | SRLG Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRLG Id (continued) | Reserved | | SRLG Id (continued) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L
L
The L bit is an attribute of the subobject. The L bit is set The L bit is an attribute of the subobject. The L bit is set
if the subobject represents a loose hop in the explicit route. if the subobject represents a loose hop in the explicit route.
If the bit is not set, the subobject represents a strict hop in If the bit is not set, the subobject represents a strict hop in
the explicit route. the explicit route.
For exclusions (as used by XRO and EXRS defined in this For exclusions (as used by XRO and EXRS defined in this
document), the L bit SHOULD be set to zero and ignored. document), the L bit SHOULD be set to zero and ignored.
Type Type
The type of the subobject (XX)
The type of the subobject [TBD by IANA]. -- RFC Editor. Please replace XX with the value define by IANA and
-- remove this note.
Length Length
The Length contains the total length of the subobject in bytes, The Length contains the total length of the subobject in bytes,
including the Type and Length fields. The Length is always 8. including the Type and Length fields. The Length is always 8.
SRLG Id SRLG Id
The 32 bit identifier of the SRLG. The 32 bit identifier of the SRLG.
Reserved Reserved
This field is reserved. It SHOULD be set to zero on
This field is reserved. It MUST be set to zero on transmission transmission and MUST be ignored on receipt.
and MUST be ignored on receipt.
3. Exclude Route List 3. Exclude Route List
The exclude route identifies a list of abstract nodes that should not The exclude route identifies a list of abstract nodes that should not
be traversed along the path of the LSP being established. It is be traversed along the path of the LSP being established. It is
RECOMMENDED to limit size of the exlude route list to a value local RECOMMENDED to limit size of the exclude route list to a value local
to the node originating the exclude route list. to the node originating the exclude route list.
3.1 Exclude Route Object (XRO) 3.1 Exclude Route Object (XRO)
Abstract nodes to be excluded from the path are specified via the Abstract nodes to be excluded from the path are specified via the
EXCLUDE_ROUTE object (XRO). The Exclude Route Class value is [TBD]. EXCLUDE_ROUTE object (XRO).
Currently one C_Type is defined, Type 1 Exclude Route. The Currently one C_Type is defined, Type 1 Exclude Route. The
EXCLUDE_ROUTE object has the following format: EXCLUDE_ROUTE object has the following format:
Class = TBD by IANA, C_Type = 1 Class = XX, C_Type = 1
-- RFC Editor. Please replace XX with the value define by IANA and
-- remove this note.
0 1 2 3 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 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 EXCLUDE_ROUTE object are a series of variable- The contents of an EXCLUDE_ROUTE object are a series of variable-
length data items called subobjects. This specification adapts ERO length data items called subobjects. This specification adapts ERO
subojbects as defined in [RFC3209], [RFC3473], and [RFC3477] for subobjects as defined in [RFC3209], [RFC3473], and [RFC3477] for
use in route exclusions. The SRLG ERO subobject as defined in use in route exclusions. The SRLG subobject as defined in Section 2
Section 2 of this document and its processing within ERO have not of this document has not been defined before. The SRLG subobject is
been defined before. The SRLG ERO subobject is defined here for use defined here for use with route exclusions.
with route exclusions.
The following subobject types are supported. The following subobject types are supported.
Type Subobject Type Subobject
-------------+------------------------------- -------------+-------------------------------
1 IPv4 prefix 1 IPv4 prefix
2 IPv6 prefix 2 IPv6 prefix
4 Unnumbered Interface ID 4 Unnumbered Interface ID
32 Autonomous system number 32 Autonomous system number
TBD by IANA SRLG XX SRLG
-- RFC Editor. Please replace XX with the value define by IANA and
-- remove this note.
The defined values for Type above are specified in [RFC3209] and in The defined values for Type above are specified in [RFC3209] and in
this document. this document.
The concept of loose or strict hops has no meaning in route The concept of loose or strict hops has no meaning in route
exclusion. The L bit, defined for ERO subobjects in [RFC3209], is exclusion. The L bit, defined for ERO subobjects in [RFC3209], is
reused here to indicate that an abstract node MUST be avoided (value reused here to indicate that an abstract node MUST be excluded (value
0) or SHOULD be avoided (value 1). 0) or SHOULD be avoided (value 1). The distinction is that the path
of an LSP must not traverse an abstract node listed in the XRO with
the L bit clear, but may traverse one with the L bit set. A node
responsible for routing an LSP (for example, for expanding a loose
hop) should attempt to minimize the number of abstract nodes listed
in the XRO with the L bit set that are traversed by the LSP according
to local policy. A node generating XRO subobjects with the L bit set
must be prepared to accept an LSP that traverses one, some, or all of
the corresponding abstract nodes.
Subobjects 1, 2, and 4 refer to an interface or a set of interfaces. Subobjects 1, 2, and 4 refer to an interface or a set of interfaces.
An Attribute octet is introduced in these subobjects to indicate the An Attribute octet is introduced in these subobjects to indicate the
attribute (e.g. interface, node, SRLG) associated with the interfaces attribute (e.g. interface, node, SRLG) associated with the interfaces
that should be excluded from the path. For instance, the attribute that should be excluded from the path. For instance, the attribute
node allows a whole node to be excluded from the path by specifying node allows a whole node to be excluded from the path by specifying
an interface of that node in the XRO subobject, in contrast to the an interface of that node in the XRO subobject, in contrast to the
attribute interface, which allows a specific interface (or multiple attribute interface, which allows a specific interface (or multiple
interfaces) to be excluded from the path without excluding the whole interfaces) to be excluded from the path without excluding the whole
nodes. The attribute SRLG allows all SRLGs associated with an nodes. The attribute SRLG allows all SRLGs associated with an
skipping to change at page 11, line 20 skipping to change at page 10, line 20
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | Reserved | Attribute | |L| Type | Length | Reserved | Attribute |
| | | |(must be zero) | | | | | |(must be zero) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TE Router ID | | TE Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID (32 bits) | | Interface ID (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L L
0 indicates that the attribute specified MUST be excluded 0 indicates that the attribute specified MUST be excluded
1 indicates that the attribute specified SHOULD be avoided 1 indicates that the attribute specified SHOULD be avoided
Attribute Attribute
Interface attribute value Interface attribute value
0 indicates that the Interface ID specified should be 0 indicates that the Interface ID specified should be
excluded or avoided excluded or avoided
Node attribute value Node attribute value
1 indicates that the node with the Router ID should be 1 indicates that the node with the Router ID should be
excluded or avoided (this can be achieved using IPv4/v6 excluded or avoided (this can be achieved using IPv4/v6
subobject as well, but is included here because it may be subobject as well, but is included here because it may be
convenient to use information from subobjects of an RRO convenient to use information from subobjects of an RRO
as defined in [RFC3477], in specifying the exclusions). as defined in [RFC3477], in specifying the exclusions).
SRLG attribute value SRLG attribute value
2 indicates that all the SRLGs associated with the 2 indicates that all the SRLGs associated with the
interface should be excluded or avoided interface should be excluded or avoided
Reserved Reserved
This field is reserved. It SHOULD be set to zero on
This field is reserved. It MUST be set to zero on transmission transmission and MUST be ignored on receipt.
and MUST be ignored on receipt.
The rest of the fields are as defined in [RFC3477]. The rest of the fields are as defined in [RFC3477].
3.1.4 Autonomous System Number Subobject 3.1.4 Autonomous System Number Subobject
The meaning of the L bit is as follows: The meaning of the L bit is as follows:
0 indicates that the abstract node specified MUST be excluded 0 indicates that the abstract node specified MUST be excluded
1 indicates that the abstract node specified SHOULD be avoided 1 indicates that the abstract node specified SHOULD be avoided
The rest of the fields are as defined in [RFC3209]. There is no The rest of the fields are as defined in [RFC3209]. There is no
Attribute octet defined. Attribute octet defined.
3.1.5 SRLG Subobject 3.1.5 SRLG Subobject
The meaning of the L bit is as follows: The meaning of the L bit is as follows:
0 indicates that the SRLG specified MUST be excluded 0 indicates that the SRLG specified MUST be excluded
1 indicates that the SRLG specified SHOULD be avoided 1 indicates that the SRLG specified SHOULD be avoided
The Attribute octet is not present. The rest of the fields are as The Attribute octet is not present. The rest of the fields are as
defined in the "SRLG ERO Subobject" section of this document. defined in the "SRLG Subobject" section of this document.
3.2 Processing Rules for the Exclude Route Object (XRO) 3.2 Processing Rules for the Exclude Route Object (XRO)
The exclude route list is encoded as a series of subobjects con- The exclude route list is encoded as a series of subobjects con-
tained in an EXCLUDE_ROUTE object. Each subobject identifies an tained in an EXCLUDE_ROUTE object. Each subobject identifies an
abstract node in the exclude route list. abstract node in the exclude route list.
Each abstract node may be a precisely specified IP address belonging Each abstract node may be a precisely specified IP address belonging
to a node, or an IP address with prefix identifying interfaces of a to a node, or an IP address with prefix identifying interfaces of a
group of nodes, or an Autonomous System. group of nodes, an Autonomous System, or an SRLG.
The Explicit Route and routing processing is unchanged from the The Explicit Route and routing processing is unchanged from the
description in [RFC3209] with the following additions: description in [RFC3209] with the following additions:
1. When a Path message is received at a node, the node MUST check 1. When a Path message is received at a node, the node MUST check
that it is not a member of any of the abstract nodes in the XRO that it is not a member of any of the abstract nodes in the XRO
if it is present in the Path message. If the node is a member of if it is present in the Path message. If the node is a member of
any of the abstract nodes in the XRO with the L-flag set to any of the abstract nodes in the XRO with the L-flag set to
"exclude", it SHOULD return a PathErr with the error code "exclude", it SHOULD return a PathErr with the error code
"Routing Problem" and error value of "Local node in Exclude "Routing Problem" and error value of "Local node in Exclude
skipping to change at page 13, line 8 skipping to change at page 11, line 46
is, it SHOULD return a PathErr with error code "Routing Problem" is, it SHOULD return a PathErr with error code "Routing Problem"
and error value of "Local node in Exclude Route". and error value of "Local node in Exclude Route".
2. Each subobject MUST be consistent. If a subobject is not con- 2. Each subobject MUST be consistent. If a subobject is not con-
sistent then the node SHOULDreturn a PathErr with error code sistent then the node SHOULDreturn a PathErr with error code
"Routing Problem" and error value "Inconsistent Subobject". An "Routing Problem" and error value "Inconsistent Subobject". An
example of an inconsistent subobject is an IPv4 Prefix subobject example of an inconsistent subobject is an IPv4 Prefix subobject
containing the IP address of a node and the attribute field is containing the IP address of a node and the attribute field is
set to "interface" or "SRLG". set to "interface" or "SRLG".
3. The subobjects in the ERO and XRO MUST NOT contradict each other. 3. The subobjects in the ERO and XRO SHOULD NOT contradict each
If a Path message is received that contains contradicting ERO and other. If a Path message is received that contains contradicting
XRO subobjects, then: ERO and XRO subobjects, then:
- subobjects in the XRO with the L flag not set (zero) MUST take - subobjects in the XRO with the L flag not set (zero) MUST take
precedence over the subobjects in the ERO - that is, a precedence over the subobjects in the ERO - that is, a
mandatory exclusion expressed in the XRO MUST be honored and mandatory exclusion expressed in the XRO MUST be honored and
an implementation MUST reject such a Path message. This means an implementation MUST reject such a Path message. This means
that a PathErr with error code "Routing Problem" and error that a PathErr with error code "Routing Problem" and error
value of "Route blocked by Exclude Route" is returned. value of "Route blocked by Exclude Route" is returned.
- subobjects in the XRO with the L flag set do not take - subobjects in the XRO with the L flag set do not take
precedence over ERO subobjects - that is, an implementation precedence over ERO subobjects - that is, an implementation
skipping to change at page 13, line 34 skipping to change at page 12, line 21
4. When choosing a next hop or expanding an explicit route to 4. When choosing a next hop or expanding an explicit route to
include additional subobjects, a node: include additional subobjects, a node:
a. MUST NOT introduce an explicit node or an abstract node that a. MUST NOT introduce an explicit node or an abstract node that
equals or is a member of any abstract node that is specified equals or is a member of any abstract node that is specified
in the Exclude Route Object with the L-flag set to "exclude". in the Exclude Route Object with the L-flag set to "exclude".
The number of introduced explicit nodes or abstract nodes The number of introduced explicit nodes or abstract nodes
with the L flag set to "avoid", which indicate that it is not with the L flag set to "avoid", which indicate that it is not
mandatory to be excluded but that it is less preferred, mandatory to be excluded but that it is less preferred,
SHOULD be minimised in the computed path. SHOULD be minimized in the computed path.
b. MUST NOT introduce links, nodes or resources identified by b. MUST NOT introduce links, nodes or resources identified by
the SRLG Id specified in the SRLG subobjects(s). The number the SRLG Id specified in the SRLG subobjects(s). The number
of introduced SLRGs with the L flag set to "avoid" SHOULD be of introduced SLRGs with the L flag set to "avoid" SHOULD be
minimised. minimized.
If these rules preclude further forwarding of the Path message, If these rules preclude further forwarding of the Path message,
the node SHOULD return a PathErr with the error code "Routing the node SHOULD return a PathErr with the error code "Routing
Problem" and error value of "Route blocked by Exclude Route". Problem" and error value of "Route blocked by Exclude Route".
Note that the subobjects in the XRO is an unordered list of Note that the subobjects in the XRO is an unordered list of
subobjects. subobjects.
A node receiving a Path message carrying an XRO MAY reject the
message if the XRO is too large or complicated for the local
implementation or as governed by local policy. In this case, the
node MUST send a PathErr message with the error code "Routing Error"
and error value "XRO Too Complex". An ingress LSR receiving this
error code/value combination MAY reduce the complexity of the XRO or
route around the node that rejected the XRO.
The XRO Class-Num is of the form 11bbbbbb so that nodes which do not The XRO Class-Num is of the form 11bbbbbb so that nodes which do not
support the XRO, forward it uninspected and do not apply the support the XRO, forward it uninspected and do not apply the
extensions to ERO processing described above. This approach is extensions to ERO processing described above. This approach is
chosen to allow route exclusion to traverse parts of the network that chosen to allow route exclusion to traverse parts of the network that
are not capable of parsing or handling the new function. Note that are not capable of parsing or handling the new function. Note that
Record Route may be used to allow computing nodes to observe Record Route may be used to allow computing nodes to observe
violations of route exclusion and attempt to re-route the LSP violations of route exclusion and attempt to re-route the LSP
accordingly. accordingly.
If a node supports the XRO, but not a particular subobject or part of If a node supports the XRO, but not a particular subobject or part of
skipping to change at page 14, line 44 skipping to change at page 13, line 39
4. Explicit Exclusion Route 4. Explicit Exclusion Route
The Explicit Exclusion Route defines abstract nodes or resources The Explicit Exclusion Route defines abstract nodes or resources
(such as links, unnumbered interfaces or labels) that must not or (such as links, unnumbered interfaces or labels) that must not or
should not be used on the path between two inclusive abstract nodes should not be used on the path between two inclusive abstract nodes
or resources in the explicit route. or resources in the explicit route.
4.1 Explicit Exclusion Route Subobject (EXRS) 4.1 Explicit Exclusion Route Subobject (EXRS)
A new ERO subobject type is defined. The Explicit Exclusion Route A new ERO subobject type is defined. The Explicit Exclusion Route
Subobject (EXRS) has type [TBD by IANA]. Although the EXRS is an ERO Subobject (EXRS) has type XX. Although the EXRS is an ERO subobject
subobject and the XRO is reusing the ERO subobject, an EXRS MUST NOT and the XRO is reusing the ERO subobject, an EXRS MUST NOT be present
be present in an XRO. An EXRS is an ERO subobject, which contains in an XRO. An EXRS is an ERO subobject, which contains one or more
one or more subobjects in its own, called EXRS subobjects. subobjects in its own, called EXRS subobjects.
-- RFC Editor. Please replace XX with the value define by IANA and
-- remove this note.
The format of the EXRS is as follows: The format of the EXRS is as follows:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | Reserved | |L| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
skipping to change at page 15, line 19 skipping to change at page 14, line 19
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | Reserved | |L| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// one or more EXRS subobjects // // one or more EXRS subobjects //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L L
It MUST be set to zero on transmission and MUST be ignored on It MUST be set to zero on transmission and MUST be ignored on
receipt. [Note: The L bit in an EXRS subobject is as defined receipt. [Note: The L bit in an EXRS subobject is as defined
for the XRO subobjects] for the XRO subobjects]
Type Type
The type of the subobject (XX).
The type of the subobject, i.e. EXRS [TBD by IANA] -- RFC Editor. Please replace XX with the value define by IANA and
-- remove this note.
Reserved Reserved
This field is reserved. It SHOULD be set to zero on
This field is reserved. It MUST be set to zero on transmission transmission and MUST be ignored on receipt.
and MUST be ignored on receipt.
EXRS subobjects EXRS subobjects
An EXRS subobject indicates the abstract node or resource to be An EXRS subobject indicates the abstract node or resource to be
excluded. The format of an EXRS subobject is exactly the same excluded. The format of an EXRS subobject is exactly the same
as the format of a subobject in the XRO. An EXRS may include as the format of a subobject in the XRO. An EXRS may include
all subobjects defined in this document for the XRO. all subobjects defined in this document for the XRO.
Thus, an EXRS for an IP hop may look as follows: Thus, an EXRS for an IP hop may look as follows:
0 1 2 3 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 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
skipping to change at page 16, line 45 skipping to change at page 15, line 45
handling of exclusions it will behave as described in [RFC3209] when handling of exclusions it will behave as described in [RFC3209] when
an unrecognized ERO subobject is encountered. This means that this an unrecognized ERO subobject is encountered. This means that this
node will return a PathErr with error code "Routing Error" and error node will return a PathErr with error code "Routing Error" and error
value "Bad Explicit Route Object" with the EXPLICIT_ROUTE object value "Bad Explicit Route Object" with the EXPLICIT_ROUTE object
inlcuded, truncated (on the left) to the offending EXRS. inlcuded, truncated (on the left) to the offending EXRS.
If the presence of EXRS precludes further forwarding of the Path If the presence of EXRS precludes further forwarding of the Path
message, the node SHOULD return a PathErr with the error code message, the node SHOULD return a PathErr with the error code
"Routing Problem" and error value "Route blocked by Exclude Route". "Routing Problem" and error value "Route blocked by Exclude Route".
A node MAY reject a Path message if the EXRS is too large or
complicated for the local implementation or as governed by local
policy. In this case, the node MUST send a PathErr message with the
error code "Routing Error" and error value "EXRS Too Complex". An
ingress LSR receiving this error code/value combination MAY reduce
the complexity of the EXRS or route around the node that rejected
the EXRS.
5. Processing of XRO together with EXRS 5. Processing of XRO together with EXRS
When an LSR performs ERO expansion and finds both the XRO in the Path When an LSR performs ERO expansion and finds both the XRO in the Path
message and EXRS in the ERO, it MUST exclude all the SRLGs, nodes, message and EXRS in the ERO, it MUST exclude all the SRLGs, nodes,
links and resources listed in both places. Where some elements links and resources listed in both places. Where some elements
appears in both lists it MUST be handled according to the stricter appears in both lists it MUST be handled according to the stricter
exclusion request - that is, if one list says that an SRLG, node, exclusion request - that is, if one list says that an SRLG, node,
link or resource must be excluded and the other says only that it link or resource must be excluded and the other says only that it
should be avoided then the element MUST be excluded. should be avoided then the element MUST be excluded.
skipping to change at page 17, line 22 skipping to change at page 16, line 32
length of 32, and an attribute value of "interface" and length of 32, and an attribute value of "interface" and
"node". Other prefix values and attribute values MAY be "node". Other prefix values and attribute values MAY be
supported. supported.
- The IPv6 Prefix subobject MUST be supported with a prefix - The IPv6 Prefix subobject MUST be supported with a prefix
length of 128, and an attribute value of "interface" and length of 128, and an attribute value of "interface" and
"node". Other prefix values and attribute values MAY be "node". Other prefix values and attribute values MAY be
supported. supported.
2. The EXRS MAY be supported. If supported, the same restrictions 2. The EXRS MAY be supported. If supported, the same restrictions
as for the XRO apply. as for the XRO apply. If not supported, an EXRS encountered
during normal ERO processing MUST be rejected as an unknown
ERO subobject as described in Section 4.2. Note that a node
SHOULD NOT parse ahead into an ERO, and if it does, MUST NOT
reject the ERO if it discovers an EXRS that applies to another
node.
3. If XRO or EXRS are supported, the implementation MUST be 3. If XRO or EXRS are supported, the implementation MUST be
compliant with the processing rules of the supported, not compliant with the processing rules of the supported, not
supported, or partially supported subobjects as specified within supported, or partially supported subobjects as specified within
this document. this document.
7. Security Considerations 7. Security Considerations
The new exclude route object poses no security exposures over and Security considerations for MPLS-TE and GMPLS signaling are covered
above [RFC3209] and [RFC3473]. Note that any security concerns that in [RFC3209] and [RFC3473]. This document does not introduce any new
exist with Explicit Routes should be considered with regard to route messages or any substantive new processing, and so those security
exclusions. considerations continue to apply.
Note that any security concerns that exist with explicit routes
should be considered with regard to route exclusions. For example,
some administrative boundaries may consider explicit routes to be
security violations and may strip EROs from the Path messages that
they process. In this case, the XRO should also be considered for
removal from the Path message.
It is possible that an arbitrarily complex XRO or EXRS sequence could
be introduced as a form of denial of service attack since its
presence will potentially cause additional processing at each node
on the path of the LSP. It should be noted that such an attack
assumes that an otherwise trusted LSR (i.e., one that has been
authenticated by its neighbors) is misbehaving. A node that receives
an XRO or EXRS sequence that it considers too complex according to
its local policy may respond with a PathErr message carrying the
error code "Routing Error" and error value "XRO Too Complex" or "EXRS
Too Complex".
8. IANA Considerations 8. IANA Considerations
It might be considered that an alternative approach would be to It might be considered that an alternative approach would be to
assign one of the bits of the ERO sub-object type field (perhaps the assign one of the bits of the ERO sub-object type field (perhaps the
top bit) to identify that a sub-object is intended for inclusion top bit) to identify that a sub-object is intended for inclusion
rather than exclusion. However, [RFC3209] states that the type field rather than exclusion. However, [RFC3209] states that the type field
(seven bits) should be assigned as 0 - 63 through IETF consensus (seven bits) should be assigned as 0 - 63 through IETF consensus
action, 64 - 95 as first come first served, and 96 - 127 are reserved action, 64 - 95 as first come first served, and 96 - 127 are reserved
for private use. It would not be acceptable to disrupt existing for private use. It would not be acceptable to disrupt existing
implementations so the only option would be to split the IETF implementations so the only option would be to split the IETF
consensus range leaving only 32 sub-object types. It is felt that consensus range leaving only 32 sub-object types. It is felt that
that would be an unacceptably small number for future expansion of that would be an unacceptably small number for future expansion of
the protocol. the protocol.
8.1 New RSVP-TE Class Numbers 8.1 New ERO Subobject Type
One new class number is required for Exclude Route object (XRO) IANA registry: RSVP PARAMETERS
defined in section "Exclude Route Object (XRO)". Subsection: Class Names, Class Numbers, and Class Types
EXCLUDE_ROUTE Add a new subobject of the existing entry for:
Class-Num of type 11bbbbbb
Suggested value 232
Defined CType: 1 (Exclude Route)
Subobjects 1, 2, 4 and 32 as for Explicit Route Object. 20 EXPLICIT_ROUTE
Additional SRLG subobject as requested in "New ERO and XRO
Subobject Type"
8.2 New ERO Subobject Type The text should read:
33 Explicit Exclusion Route subobject (EXRS)
The Explicit Exclusion Route subobject (EXRS) is defined in section The Explicit Exclusion Route subobject (EXRS) is defined in section
"Explicit Exclusion Route Subobject (EXRS)". This subobject may be "Explicit Exclusion Route Subobject (EXRS)". This subobject may be
present in the Explicit Route Object, but not in the Route Record present in the Explicit Route Object, but not in the Route Record
Object, nor in the new Exclude Route Object. Object, nor in the new Exclude Route Object and should not be listed
among the subobjects for those objects.
Suggested value 33 Suggested value 33
8.3 New ERO and XRO Subobject Type 8.2 New RSVP-TE Class Numbers
The SRLG subobject is defined in section "SRLG ERO Subobject". This IANA registry: RSVP PARAMETERS
subobject may be present in the Exclude Route Object or in the Subsection: Class Names, Class Numbers, and Class Types
Explicit Route Object, but not in the Route Record Object.
Suggested value 34 One new class number is required for Exclude Route object (XRO)
defined in Section "Exclude Route Object (XRO)".
8.4 New Error Codes EXCLUDE_ROUTE
Class-Num of type 11bbbbbb
Suggested value 232
Defined CType: 1 (Exclude Route)
New error values are needed for the error code 'Routing Problem' Subobjects 1, 2, 4 and 32 as for Explicit Route Object.
(24). Additional subobject as requested in Section "New ERO and XRO
Subobject Type". The text should appear as:
Sub-object type
1 IPv4 address [RFC3209]
2 IPv6 address [RFC3209]
4 Unnumbered Interface ID [RFC3477]
32 Autonomous system number [RFC3209]
33 Explicit Exclusion Route subobject (EXRS) [this doc]
34 SRLG [this doc]
The SRLG subobject is defined in section "SRLG Subobject". The value
34 is suggested.
8.3 New Error Codes
IANA registry: RSVP PARAMETERS
Subsection: Error Codes and Globally-Defined Error Value Sub-Codes
New Error Values sub-codes are needed for the Error Code 'Routing
Problem' (24).
Unsupported Exclude Route Subobject Type Suggested value 64 Unsupported Exclude Route Subobject Type Suggested value 64
Inconsistent Subobject Suggested value 65 Inconsistent Subobject Suggested value 65
Local Node in Exclude Route Suggested value 66 Local Node in Exclude Route Suggested value 66
Route Blocked by Exclude Route Suggested value 67 Route Blocked by Exclude Route Suggested value 67
XRO Too Complex Suggested value 68
EXRS Too Complex Suggested value 69
9. Acknowledgments 9. Acknowledgments
This document reuses text from [RFC3209] for the description of This document reuses text from [RFC3209] for the description of
EXCLUDE_ROUTE. EXCLUDE_ROUTE.
The authors would like to express their thanks to Lou Berger, Steffen The authors would like to express their thanks to Lou Berger, Steffen
Brockmann, Igor Bryskin, Dimitri Papadimitriou, Cristel Pelsser, and Brockmann, Igor Bryskin, Dimitri Papadimitriou, Cristel Pelsser, and
Richard Rabbat for their considered opinions on this draft. Also Richard Rabbat for their considered opinions on this draft. Also
thanks to Yakov Rekhter for reminding us about SRLGs! thanks to Yakov Rekhter for reminding us about SRLGs!
Thanks to Eric Gray for providing GenArt review and to Ross Callon
for his comments.
10. References 10. References
10.1 Normative References 10.1 Normative References
[GMPLS-RTG]
Kompella, K. and Y. Rekhter, "Routing Extensions in
Support of Generalized Multi-Protocol Label Switching",
draft-ietf-ccamp-gmpls-routing, work in progress.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001. Tunnels", RFC 3209, December 2001.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic (GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links
in Resource ReSerVation Protocol - Traffic Engineering in Resource ReSerVation Protocol - Traffic Engineering
(RSVP-TE)", RFC 3477, January 2003. (RSVP-TE)", RFC 3477, January 2003.
[RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in
Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4202, October 2005.
10.2 Informational References 10.2 Informational References
[CRANKBACK] [CRANKBACK]
Farrel, A., Satyanarayana, A., Iwata, A., Ash, G., and S. Farrel, A., Satyanarayana, A., Iwata, A., Ash, G., and S.
Marshall-Unitt, "Crankback Signaling Extensions for MPLS Marshall-Unitt, "Crankback Signaling Extensions for MPLS
Signaling", draft-ietf-ccamp-crankback, work in progress. Signaling", draft-ietf-ccamp-crankback, work in progress.
[INTERAS] De Cnodder, S. and C. Pelsser, "Protection for inter-AS
MPLS tunnels", draft-decnodder-ccamp-interas-protection,
work in progress.
[INTERAS-REQ]
Zhang, R. and JP. Vasseur, "MPLS Inter-AS Traffic
Engineering requirements",
draft-ietf-tewg-interas-mpls-te-req, work in progress.
[MPLS-BUNDLE]
Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling
in MPLS Traffic Engineering", draft-ietf-mpls-bundle, work
in progress.
[OVERLAY] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter,
"GMPLS UNI: RSVP Support for the Overlay Model",
draft-ietf-ccamp-gmpls-overlay, work in progress.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630, (TE) Extensions to OSPF Version 2", RFC 3630,
September 2003. September 2003.
[RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate
System (IS-IS) Extensions for Traffic Engineering (TE)", System (IS-IS) Extensions for Traffic Engineering (TE)",
RFC 3784, June 2004. RFC 3784, June 2004.
[RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, [RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau,
"Multiprotocol Label Switching (MPLS) Traffic Engineering "Multiprotocol Label Switching (MPLS) Traffic Engineering
(TE) Management Information Base (MIB)", RFC 3812, (TE) Management Information Base (MIB)", RFC 3812,
June 2004. June 2004.
[RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter,
"Generalized Multiprotocol Label Switching (GMPLS)
User-Network Interface (UNI): Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Support for the
Overlay Model", RFC 4208, October 2005.
[RFC4216] Zhang, R. and JP. Vasseur, "MPLS Inter-Autonomous System
(AS) Traffic Engineering (TE) Requirements", RFC 4216,
November 2005.
11. Authors' Addresses 11. Authors' Addresses
Cheng-Yin Lee Cheng-Yin Lee
Email: leecy@sympatico.ca Email: c.yin.lee@gmail.com
Adrian Farrel Adrian Farrel
Old Dog Consulting Old Dog Consulting
Phone: +44 (0) 1978 860944 Phone: +44 (0) 1978 860944
Email: adrian@olddog.co.uk Email: adrian@olddog.co.uk
Stefaan De Cnodder Stefaan De Cnodder
Alcatel Alcatel
Francis Wellesplein 1 Francis Wellesplein 1
B-2018 Antwerp B-2018 Antwerp
skipping to change at page 23, line 18 skipping to change at page 23, line 18
Discussion on the length of the XRO: the XRO is bounded by the length Discussion on the length of the XRO: the XRO is bounded by the length
of the RRO of the primary LSP. of the RRO of the primary LSP.
Suppose that SRLG protection is required, and the ASs crossed by the Suppose that SRLG protection is required, and the ASs crossed by the
main LSP use a consistent way of allocating SRLG-ids to the links main LSP use a consistent way of allocating SRLG-ids to the links
(i.e. the ASs use a single SRLG space). In this case, the SRLG-ids (i.e. the ASs use a single SRLG space). In this case, the SRLG-ids
of each link used by the main LSP can be recorded by means of the of each link used by the main LSP can be recorded by means of the
RRO, which are then used by the XRO. If the SRLG-ids are only RRO, which are then used by the XRO. If the SRLG-ids are only
meaningfull local to the AS, putting SRLG-ids in the XRO crossing meaningfull local to the AS, putting SRLG-ids in the XRO crossing
many ASs makes no sense. More details on the method of providing many ASs makes no sense. To provide SRLG protection for inter-AS LSPs
SRLG protection for inter-AS LSPs can be found in [INTERAS]. the link IP address of the inter-AS link used by the primary LSP can
Basically, the link IP address of the inter-AS link used by the be put into the XRO of the Path message of the detour LSP or bypass
primary LSP is put into the XRO of the Path message of the detour LSP tunnel. The ASBR where the detour LSP or bypass tunnel is entering
or bypass tunnel. The ASBR where the detour LSP or bypass tunnel is the AS can translate this into the list of SRLG-ids known to the
entering the AS can translate this into the list of SRLG-ids known to local AS.
the local AS.
Discussion on the length of the XRO: the XRO only contains 1 Discussion on the length of the XRO: the XRO only contains 1
subobject, which contains the IP address of the inter-AS link subobject, which contains the IP address of the inter-AS link
traversed by the primary LSP (assuming that the primary LSP and traversed by the primary LSP (assuming that the primary LSP and
detour LSP or bypass tunnel are leaving the AS in the same area, and detour LSP or bypass tunnel are leaving the AS in the same area, and
they are also entering the next AS in the same area). they are also entering the next AS in the same area).
A.3 Protection in the GMPLS overlay model A.3 Protection in the GMPLS overlay model
When an edge-node wants to establish an LSP towards another edge-node When an edge-node wants to establish an LSP towards another edge-node
over an optical core network as described in [OVERLAY] (see figure over an optical core network as described in [RFC4208] (see figure
A.2), the XRO can be used for multiple purposes. A.2), the XRO can be used for multiple purposes.
Overlay Overlay Overlay Overlay
Network +--------------------------------+ Network Network +--------------------------------+ Network
+----------+ | | +----------+ +----------+ | | +----------+
| +----+ | | +-----+ +-----+ +-----+ | | +----+ | | +----+ | | +-----+ +-----+ +-----+ | | +----+ |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| --+ EN1+-+-----+--+ CN1 +---+ CN2 +---+ CN3 +---+-----+-+ EN3+-- | | --+ EN1+-+-----+--+ CN1 +---+ CN2 +---+ CN3 +---+-----+-+ EN3+-- |
| | | | +--+--+ | | | | +---+--+ | | | | | | | | +--+--+ | | | | +---+--+ | | | |
| +----+ | | | +--+--+ +--+--+ +--+--+ | | | +----+ | | +----+ | | | +--+--+ +--+--+ +--+--+ | | | +----+ |
skipping to change at page 26, line 33 skipping to change at page 26, line 33
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity Disclaimer of Validity
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The IETF Trust (2006).
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the This document is subject to the rights, licenses and restrictions
Internet Society. contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
 End of changes. 76 change blocks. 
162 lines changed or deleted 219 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/