draft-ietf-ccamp-rsvp-te-exclude-route-01.txt   draft-ietf-ccamp-rsvp-te-exclude-route-02.txt 
CCAMP Working Group CY Lee CCAMP Working Group CY Lee
Internet Draft A. Farrel Internet Draft A. Farrel
Expiration Date: June 2004 S. De Cnodder Expiration Date: January 2005 S. De Cnodder
December 2003 July 2004
Exclude Routes - Extension to RSVP-TE Exclude Routes - Extension to RSVP-TE
<draft-ietf-ccamp-rsvp-te-exclude-route-01.txt> <draft-ietf-ccamp-rsvp-te-exclude-route-02.txt>
1. Status of this memo 1. Status of this memo
This document is an Internet-Draft and is in full conformance with By submitting this Internet-Draft, I certify that any applicable
all provisions of Section 10 of RFC2026. patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 a "work in progress."
To view the list Internet-Draft Shadow Directories, see The list of current Internet-Drafts can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
2. Abstract 2. Abstract
The current RSVP-TE specification, "RSVP-TE: Extensions to RSVP for The current RSVP-TE specification, "RSVP-TE: Extensions to RSVP for
LSP Tunnels" (RFC 3209) and GMPLS extensions to RSVP-TE, "Generalized LSP 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.
skipping to change at page 2, line 5 skipping to change at page 2, line 11
head end it may be useful to specify and signal abstract nodes and head end it may be useful to specify and signal abstract nodes and
resources that are to be explicitly excluded from routes. These resources that are to be explicitly excluded from routes. These
exclusions may apply to the whole path, or to parts of a path between exclusions may apply to the whole path, or to parts of a path between
two abstract nodes specified in an explicit path. How Shared Risk two abstract nodes specified in an explicit path. How Shared Risk
Link Groups (SLRGs) can be excluded is also specified in this Link Groups (SLRGs) can be excluded is also specified in this
document. document.
This document specifies ways to communicate route exclusions during This document specifies ways to communicate route exclusions during
path setup using RSVP-TE. path setup using RSVP-TE.
2.1 Future Work 2.1 Changes compared to version 01
Future work on this document may include the following.
- Exclusion of unnumbered links.
- Line up with LSP attribute. This could mean that EXRS has to be
revised.
- Convergence of SRLG identification with formats defined in other
drafts.
- Update MIB section.
2.2 Changes compared to version 00
- This section is added.
- Tolerance field in SRLG subobject is removed.
- References updated. References updated.
- Editorial updates. - Editorial updates.
- XRO processing rules further detailed. - Added Unnumbered Interface exclusions
- Recommendation added to limit the size of the exlude route list to
a value local to the node originating the exclude route list.
- Section added with minimum compliance statement.
- Acknowledgements updated. - Acknowledgements updated.
- IPR section. - IPR section.
- Appendix A with applications is added. - Appendix A with applications is added.
3. Conventions used in this document 3. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 3, line 33 skipping to change at page 3, line 18
object and a new ERO subobject are introcuded respectively. object and a new ERO subobject are introcuded respectively.
i) A new RSVP-TE object is introduced to convey the Exclude Route i) 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).
ii) The second type of exclusion is achieved through a modification ii) The second type of exclusion is achieved through a modification
to the existing ERO. A new subobject type the Explicit Exclude to the existing ERO. A new subobject type the Explicit Exclude
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.
SRLGs allow the definition of resources or groups of resources that The knowledge of SRLGs, as defined in [INTERAS-REQ], may be used to
share the same risk of failure. The knowledge of SRLGs may be used compute diverse paths that can be used for protection. In systems
to 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 of a path or between two abstract nodes specified in an expli- whole of a path or between two abstract nodes specified in an expli-
cit path. cit path.
This document introduces an ERO subobject to indicate an SRLG to be This document introduces an ERO subobject to indicate an SRLG to be
signaled in either of the two exclusion methods described above. This signaled in either of the two exclusion methods described above. This
subobject might also be appropriate for use within Explicit Routes or subobject might also be appropriate for use within Explicit Routes or
Record Routes, but that discussion is outside the scope of this docu- Record Routes, but that discussion is outside the scope of this docu-
ment. ment.
skipping to change at page 5, line 29 skipping to change at page 5, line 13
guration allows the exclusion of certain resources. guration 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 means be necessary to signal those exclusions. This document offers a means
of doing this signaling. of doing this signaling.
5. Shared Risk Link Groups 5. 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 [GMPLS-
OSPF]. These 32 bits are divided into an 8 bit type field and a 24 OSPF].
bit identifier in [CCAMP-SRLG].
5.1 SRLG ERO Subobject 5.1 SRLG ERO Subobject
The format of the ERO and its subobjects are defined in [RSVP-TE]. The format of the ERO and its subobjects are defined in [RSVP-TE].
The new SRLG subobject is defined by this document as follows. The new SRLG subobject is defined by this document 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 | SRLG Id (4 bytes) | |L| Type | Length | SRLG Id (4 bytes) |
skipping to change at page 6, line 5 skipping to change at page 5, line 35
| 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, the L bit SHOULD be set to zero and ignored. For exclusions (as used by XRO and EXRS defined in this docu-
ment), the L bit SHOULD be set to zero and ignored.
Type Type
The type of the subobject [TBD]. The type of the subobject [TBD].
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.
skipping to change at page 7, line 11 skipping to change at page 6, line 42
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. The subobjects are identical length data items called subobjects. The subobjects are identical
to those defined in [RSVP-TE] and [GMPLS-RSVP-TE] for use in EROs. to those defined in [RSVP-TE] and [GMPLS-RSVP-TE] for use in EROs.
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
32 Autonomous system number 32 Autonomous system number
TBD SRLG TBD SRLG
The defined values for Type above are specified in [RSVP-TE] and The defined values for Type above are specified in [RSVP-TE] and
in this document. in this document.
The concept of loose or strict hops has no meaning in route exclu- The concept of loose or strict hops has no meaning in route exclu-
sion. The L bit, defined for ERO subobjects in [RSPV-TE], is re- sion. The L bit, defined for ERO subobjects in [RSPV-TE], is re-
used here to indicate that an abstract node MUST be avoided (value used here to indicate that an abstract node MUST be avoided (value
0) or SHOULD be avoided (value 1). 0) or SHOULD be avoided (value 1).
skipping to change at page 8, line 14 skipping to change at page 7, line 46
node node
1 indicates that the node or set of nodes associated with the 1 indicates that the node or set of nodes associated with the
IP prefix should be excluded or avoided IP prefix should be excluded or avoided
SRLG SRLG
2 indicates that all the SRLGs associated with the IP prefix 2 indicates that all the SRLGs associated with the IP prefix
should be excluded or avoided should be excluded or avoided
Resvd
Zero on transmission. Ignored on receipt.
The rest of the fields are as defined in [RSVP-TE]. The rest of the fields are as defined in [RSVP-TE].
6.1.2 Subobject 2: IPv6 Prefix 6.1.2 Subobject 2: IPv6 Prefix
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 | IPv6 address (16 bytes) | |L| Type | Length | IPv6 address (16 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) | | IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) | | IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) | | IPv6 address (continued) |
skipping to change at page 8, line 36 skipping to change at page 8, line 19
| IPv6 address (continued) | | IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) | | IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) | | IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) | Prefix Length | Attribute | | IPv6 address (continued) | Prefix Length | Attribute |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L L
0 indicates that the abstract node specified MUST be excluded 0 indicates that the attribute specified MUST be excluded
1 indicates that the abstract node specified SHOULD be avoided 1 indicates that the attribute specified SHOULD be avoided
Attribute Attribute
interface interface
0 indicates that the interface or set of interfaces associ- 0 indicates that the interface or set of interfaces associ-
ated with the IP prefix should be excluded or avoided ated with the IP prefix should be excluded or avoided
node node
skipping to change at page 9, line 4 skipping to change at page 8, line 35
0 indicates that the interface or set of interfaces associ- 0 indicates that the interface or set of interfaces associ-
ated with the IP prefix should be excluded or avoided ated with the IP prefix should be excluded or avoided
node node
1 indicates that the node or set of nodes associated with the 1 indicates that the node or set of nodes associated with the
IP prefix should be excluded or avoided IP prefix should be excluded or avoided
SRLG SRLG
2 indicates that all the SRLG associated with the IP prefix 2 indicates that all the SRLG associated with the IP prefix
should be excluded or avoided should be excluded or avoided
Resvd
Zero on transmission. Ignored on receipt.
The rest of the fields are as defined in [RSVP-TE]. The rest of the fields are as defined in [RSVP-TE].
6.1.3 Subobject 32: Autonomous System Number 6.1.3 Subobject 32: Autonomous System Number
The L bit of an Autonomous System Number subobject has meaning in The L bit of an Autonomous System Number subobject has meaning in
an Exclude Route (contrary to its usage in an Explict Route an Exclude Route (contrary to its usage in an Explict Route
defined in [RSVP-TE]. The meaning is as for other subobjects defined in [RSVP-TE]. The meaning is as for other subobjects
described above. That is: described above. That is:
0 indicates that the abstract node specified MUST be excluded 0 indicates that the abstract node specified MUST be excluded
skipping to change at page 9, line 22 skipping to change at page 9, line 4
6.1.3 Subobject 32: Autonomous System Number 6.1.3 Subobject 32: Autonomous System Number
The L bit of an Autonomous System Number subobject has meaning in The L bit of an Autonomous System Number subobject has meaning in
an Exclude Route (contrary to its usage in an Explict Route an Exclude Route (contrary to its usage in an Explict Route
defined in [RSVP-TE]. The meaning is as for other subobjects defined in [RSVP-TE]. The meaning is as for other subobjects
described above. That is: described above. That is:
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 [RSVP-TE]. There is no The rest of the fields are as defined in [RSVP-TE]. There is no
Attribute octet defined. Attribute octet defined.
6.1.4 Subobject TBD: SRLG 6.1.4 Subobject TBD: SRLG
The meaning of the L bit is as follows:
0 indicates that the SRLG specified MUST be excluded
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 ERO Subobject" section of this document.
6.1.5 Subobject 4: Unnumbered Interface ID Subobject
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | Reserved | Attribute |
| | | |(must be zero) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L
0 indicates that the attribute specified MUST be excluded
1 indicates that the attribute specified SHOULD be avoided
Attribute
interface
0 indicates that the Interface ID specified should be excluded
or avoided
node
1 indicates that the node with the Router ID should be
excluded or avoided (this can be achieved using IPv4/v6
subobject as well, but is included here because it may be
convenient to use subobjects from RRO, in specifying the
exclusions)
SRLG
2 indicates that all the SRLGs associated with the interface
should be excluded or avoided
Reserved
Zero on transmission. Ignored on receipt.
The rest of the fields are as defined in [MPLS_UNNUM].
6.2. Semantics and Processing Rules for the Exclude Route Object (XRO) 6.2. Semantics and Processing Rules for the Exclude Route Object (XRO)
The exclude route list is encoded as a series of subobjects contained The exclude route list is encoded as a series of subobjects con-
in an EXCLUDE_ROUTE object. Each subobject identifies an abstract tained in an EXCLUDE_ROUTE object. Each subobject identifies an
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 belong-
to a node, or an IP address with prefix identifying interfaces of a ing to a node, or an IP address with prefix identifying interfaces
group of nodes, or an Autonomous System. of a group of nodes, or an Autonomous System.
The Explicit Route and routing processing is unchanged from the The Explicit Route and routing processing is unchanged from the
description in [RSVP-TE] with the following additions: description in [RSVP-TE] with the following additions:
a. When a Path message is received at a node, the node must check a. 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 if 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 any 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 "exclude", of the abstract nodes in the XRO with the L-flag set to "exclude",
it should return a PathErr with the error code "Routing Problem" it should return a PathErr with the error code "Routing Problem"
and error value of "Local node in Exclude Route". If there are and error value of "Local node in Exclude Route". If there are
skipping to change at page 12, line 4 skipping to change at page 12, line 30
Subobject (EXRS) has type [TBD]. The EXRS may not be present in an Subobject (EXRS) has type [TBD]. The EXRS may not be present in an
RRO or XRO. RRO or XRO.
The format of the EXRS is as follows. The format of the EXRS is as follows.
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--------------//---------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--------------//---------------+
|L| Type | Length | EXRS subobjects | |L| Type | Length | EXRS subobjects |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--------------//---------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--------------//---------------+
L L
ignored and must be zero ignored and must be zero
[Note: The L bit in an ERES subobject is as defined for the XRO [Note: The L bit in an EXRS subobject is as defined for the XRO
subobjects] subobjects]
Type Type
The type of the subobject, i.e. EXRS [TBD] The type of the subobject, i.e. EXRS [TBD]
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 this field is exactly the format of an excluded. The format of this field is exactly the format of an
XRO subobject and may include an SRLG subobject. Both subob- XRO subobject and may include an SRLG subobject. Both subob-
jects are as described earlier in this document. jects are as described earlier in this document.
skipping to change at page 13, line 11 skipping to change at page 13, line 43
Exclusions may indicate explicit nodes, abstract nodes or Autonomous Exclusions may indicate explicit nodes, abstract nodes or Autonomous
Systems that must not be traversed on the path to the next abstract Systems that must not be traversed on the path to the next abstract
node indicated in the ERO. node indicated in the ERO.
Exclusions may also indicate resources (such as unnumbered inter- Exclusions may also indicate resources (such as unnumbered inter-
faces, link ids, labels) that must not be used on the path to the faces, link ids, labels) that must not be used on the path to the
next abstract node indicated in the ERO. next abstract node indicated in the ERO.
SRLGs may also be indicated for exclusion from the path to the next SRLGs may also be indicated for exclusion from the path to the next
abstract node in the ERO by the inclusion of an EXRO Subobject con- abstract node in the ERO by the inclusion of an EXRO Subobject con-
taining an SRLG subobject. If the Tolerance value in the SRLG subob- taining an SRLG subobject. If the L-bit value in the SRLG subobject
ject is zero, the resources (nodes, links, etc.) identified by the is zero, the resources (nodes, links, etc.) identified by the SRLG
SRLG must not be used on the path to the next abstract node indicated MUST not be used on the path to the next abstract node indicated in
in the ERO. If the Tolerance value is non- zero, the resources iden- the ERO. If the L-bit is set, the resources identified by the SRLG
tified by the SRLG should be avoided, but may be used in preference SHOULD be avoided.
to resources associated with another SRLG indicated for exclusion if
that SRLG has a (numerically) lower Tolerance value.
The subobjects in the ERO and EXRS SHOULD not contradict each other. The subobjects in the ERO and EXRS SHOULD not contradict each other.
If they do contradict, the subobjects with the L bit not set, strict If they do contradict, the subobjects with the L bit not set, strict
or MUST be excluded, respectively, in the ERO or XRO MUST take pre- or MUST be excluded, respectively, in the ERO or XRO MUST take pre-
cedence. If there is still a conflict, the subobjects in the ERO cedence. If there is still a conflict, the subobjects in the ERO
MUST take precedence. MUST take precedence.
If a node is called upon to process an EXRS and does not support han- If a node is called upon to process an EXRS and does not support han-
dling of exclusions it will return a PathErr with a "Bad dling of exclusions it will return a PathErr with a "Bad
EXPLICIT_ROUTE object" error. EXPLICIT_ROUTE object" error.
skipping to change at page 14, line 7 skipping to change at page 14, line 36
of 128, and an attriubute value of "interface" and "node". Other of 128, and an attriubute value of "interface" and "node". Other
prefix values and attribute values MAY be supported. prefix values and attribute values MAY be supported.
B. The EXRS SHOULD be supported. If supported, the same restrictions B. The EXRS SHOULD be supported. If supported, the same restrictions
as for the XRO apply. as for the XRO apply.
C. If XRO or EXRS are supported, the implementation MUST be compliant C. If XRO or EXRS are supported, the implementation MUST be compliant
with the processing rules of the supported, not supported, or par- with the processing rules of the supported, not supported, or par-
tially supported subobjects as specified within this document. tially supported subobjects as specified within this document.
9. Security 9. Security Considerations
The new exclude route object poses no security exposures over and The new exclude route object poses no security exposures over and
above [RSVP-TE] and [GMPLS-RSVP-TE]. Note that any security con- above [RSVP-TE] and [GMPLS-RSVP-TE]. Note that any security con-
cerns that exist with Explicit Routes should be considered with cerns that exist with Explicit Routes should be considered with
regard to route exclusions. regard to route exclusions.
10. IANA Considerations 10. IANA Considerations
It might be considered that a possible approach would be to 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
rather than exclusion. However, [RSVP-TE] states that the type
field (seven bits) should be assigned as 0 - 63 through IETF con-
sensus action, 64 - 95 as first come first served, and 96 - 127
are reserved for private use. It would not be acceptable to dis-
rupt existing implementations so the only option would be to split
the IETF consensus range leaving only 32 sub-object types. It is
felt that that would be an unacceptably small number for future
expansion of the protocol.
10.1. New Class Numbers 10.1. New Class Numbers
One new class number is required. One new class number is required.
EXCLUDE_ROUTE EXCLUDE_ROUTE
Class-Num = 011bbbbb Class-Num = 011bbbbb
CType: 1 CType: 1
10.2. New Subobject Types 10.2. New Subobject Types
skipping to change at page 15, line 8 skipping to change at page 15, line 50
This document reuses text from [RSVP-TE] for the description of This document reuses text from [RSVP-TE] 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!
12. Intellectual Property Considerations 12. Intellectual Property Considerations
This section is taken from Section 10.4 of [RFC-2026]. This following is taken from Section 10.4 of [RFC-2026].
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to per- intellectual property or other rights that might be claimed to per-
tain to the implementation or use of the technology described in this tain to the implementation or use of the technology described in this
document or the extent to which any license under such rights might document or the extent to which any license under such rights might
or might not be available; neither does it represent that it has made or might not be available; neither does it represent that it has made
any effort to identify any such rights. Information on the IETF's any effort to identify any such rights. Information on the IETF's
procedures with respect to rights in standards-track and standards- procedures with respect to rights in standards-track and standards-
related documentation can be found in BCP-11. Copies of claims of related documentation can be found in BCP-11. Copies of claims of
rights made available for publication and any assurances of licenses rights made available for publication and any assurances of licenses
skipping to change at page 16, line 7 skipping to change at page 16, line 50
[GMPLS-RSVP-TE] Berger, L., (Editor), "Generalized Multi-Protocol Label [GMPLS-RSVP-TE] Berger, L., (Editor), "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions", Protocol-Traffic Engineering (RSVP-TE) Extensions",
RFC 3473, January 2003. RFC 3473, January 2003.
[GMPLS-OSPF] K. Kompela, Y. Rekhter, (Editors) "OSPF Extensions [GMPLS-OSPF] K. Kompela, Y. Rekhter, (Editors) "OSPF Extensions
in Support of Generalized MPLS", Internet Draft, in Support of Generalized MPLS", Internet Draft,
draft-ietf-ccamp-ospf-gmpls-extensions-12.txt, draft-ietf-ccamp-ospf-gmpls-extensions-12.txt,
October 2003 (work in progress). October 2003 (work in progress).
[MPLS-TE-MIB] C. Srinivasan, et al., "Multiprotocol Label [MPLS-UNNUM] Kompella, K., Rekhter, Y., "Signalling Unnumbered
Switching (MPLS) Traffic Engineering Management Links in RSVP-TE", RFC 3477, January 2003.
Information Base", Internet Draft, draft-ietf-mpls-
te-mib-09.txt, November 2002 (work in progress). www.ietf.org/ internet-drafts/draft-ietf-mpls-bundle-04.txt
13.2 Informational References 13.2 Informational References
[MPLS-BUNDLE] Kompella, K., Rekhter, Y., and Berger, L., [MPLS-BUNDLE] Kompella, K., Rekhter, Y., and Berger, L.,
"Link Bundling in MPLS Traffic Engineering", "Link Bundling in MPLS Traffic Engineering",
Internet Draft, draft-ietf-mpls-bundle-04.txt, Internet Draft, draft-ietf-mpls-bundle-04.txt,
July 2002, (work in progress). July 2002, (work in progress).
[MPLS-UNNUM] Kompella, K., Rekhter, Y., "Signalling Unnumbered [MPLS-TE-MIB] C. Srinivasan, et al., "Multiprotocol Label
Links in RSVP-TE", RFC 3477, January 2003. Switching (MPLS) Traffic Engineering Management
Information Base", Internet Draft, draft-ietf-mpls-
te-mib-09.txt, November 2002 (work in progress).
[CCAMP-SRLG] D. Papadimitriou, et al., "Shared Risk Link Groups [INTERAS-REQ] R. Zhang, JP Vasseur (Editors), "MPLS Inter-AS Traffic
Encoding and Processing", Internet Draft, Engineering Requirements", Internet Draft,
draft-papadimitriou-ccamp-srlg-processing-01.txt, draft-ietf-tewg-interas-mpls-te-req-03.txt, December
November 2002 (work in progress). 2003 (work in progress).
[INTERAS] De Cnodder, S., Pelsser, C., "Protection for [INTERAS] De Cnodder, S., Pelsser, C., "Protection for
inter-AS MPLS tunnels", Internet Draft, draft- inter-AS MPLS tunnels", Internet Draft, draft-
decnodder-mpls-interas-protection-00.txt, February decnodder-mpls-interas-protection-00.txt, February
2003, (work in progress). 2003, (work in progress).
[OVERLAY] Swallow, G., Drake, J., Ishimatsu, H., Rekhter, Y., [OVERLAY] Swallow, G., Drake, J., Ishimatsu, H., Rekhter, Y.,
GMPLS RSVP Support for the Overlay Model", Internet GMPLS RSVP Support for the Overlay Model", Internet
Draft, draft-ccamp-gmpls-overlay-02.txt, October Draft, draft-ccamp-gmpls-overlay-02.txt, October
2003, (work in progress). 2003, (work in progress).
skipping to change at page 17, line 4 skipping to change at page 17, line 47
[ISIS-TE] Smit, H., Li, T., "IS-IS extensions for Traffic [ISIS-TE] Smit, H., Li, T., "IS-IS extensions for Traffic
Engineering", Internet Draft, draft-ietf-isis- Engineering", Internet Draft, draft-ietf-isis-
traffic-05.txt, August 2003, (work in progress). traffic-05.txt, August 2003, (work in progress).
[CRANKBACK] Farrel, A., (Editor), "Crankback Routing Extensions [CRANKBACK] Farrel, A., (Editor), "Crankback Routing Extensions
for MPLS Signaling", Internet Draft, draft-iwata-mpls- for MPLS Signaling", Internet Draft, draft-iwata-mpls-
crankback-05.txt, March 2003, (work in progress). crankback-05.txt, March 2003, (work in progress).
14. Authors' Information 14. Authors' Information
Cheng-Yin Lee Cheng-Yin Lee
Alcatel Alcatel
600 March Road. 600 March Road.
Ottawa, Ontario Ottawa, Ontario
Canada K2K 2E6 Canada K2K 2E6
email: Cheng-Yin.Lee@alcatel.com EMail: Cheng-Yin.Lee@alcatel.com
Adrian Farrel Adrian Farrel
Movaz Networks, Inc. Old Dog Consulting
7926 Jones Branch Drive, Suite 615 Phone: +44 (0) 1978 860944
McLean VA, 22102 USA EMail: adrian@olddog.co.uk
Phone: +1-703-847-1867
Email: afarrel@movaz.com
Stefaan De Cnodder Stefaan De Cnodder
Alcatel Alcatel
Francis Wellesplein 1 Francis Wellesplein 1
B-2018 Antwerp, Belgium B-2018 Antwerp, Belgium
email: stefaan.de_cnodder@alcatel.be EMail: stefaan.de_cnodder@alcatel.be
15. Appendix A: applications Appendix A: applications
This section describes some applications that can make use of the This section describes some applications that can make use of the
XRO. The intention is to show that the XRO is not an application XRO. The intention is to show that the XRO is not an application
specific object, but that it can be used for multiple purposes. In a specific object, but that it can be used for multiple purposes. In a
few examples, other solutions might be possible for that particular few examples, other solutions might be possible for that particular
case but the intention is to show that also a single object can be case but the intention is to show that also a single object can be
used for all the examples, hence making the XRO a rather generic used for all the examples, hence making the XRO a rather generic
object without having to define a solution and new objects for each object without having to define a solution and new objects for each
new application. new application.
15.1 Inter-area LSP protection A.1 Inter-area LSP protection
One method to establish an inter-area LSP is where the ingress router One method to establish an inter-area LSP is where the ingress router
selects an ABR, and then the ingress router computes a path towards selects an ABR, and then the ingress router computes a path towards
this selected ABR such that the configured constraints of the LSP are this selected ABR such that the configured constraints of the LSP are
fulfilled. In the example of figure A.1, an LSP has to be established fulfilled. In the example of figure A.1, an LSP has to be established
from node A in area 1 to node C in area 2. If no loose hops are con- from node A in area 1 to node C in area 2. If no loose hops are con-
figured, then the computed ERO at A could looks as follows: (A1- figured, then the computed ERO at A could looks as follows: (A1-
strict, A2-strict, ABR1-strict, C-loose). When the Path message strict, A2-strict, ABR1-strict, C-loose). When the Path message
arrives at ABR1, then the ERO is (ABR1-strict, C-loose) and it can be arrives at ABR1, then the ERO is (ABR1-strict, C-loose) and it can be
expanded by ABR1 to (B1-strict, ABR3-strict, C-loose). Similar, at expanded by ABR1 to (B1-strict, ABR3-strict, C-loose). Similar, at
skipping to change at page 18, line 51 skipping to change at page 19, line 50
example). This means that when ABR2 generates an XRO, it may remove example). This means that when ABR2 generates an XRO, it may remove
the nodes in area 0 from the XRO but not ABR3. Note that not doing the nodes in area 0 from the XRO but not ABR3. Note that not doing
this would not harm in this example because there is no path from this would not harm in this example because there is no path from
ABR4 to C via ABR3 in area2. If there would be a links between ABR4- ABR4 to C via ABR3 in area2. If there would be a links between ABR4-
ABR3 and ABR3-C, then it is required to have ABR3 in the XRO gen- ABR3 and ABR3-C, then it is required to have ABR3 in the XRO gen-
erated by ABR2. erated by ABR2.
Discussion on the length of the XRO: when link or node protection is Discussion on the length of the XRO: when link or node protection is
requested, the length of the XRO is bounded by the length of the RRO requested, the length of the XRO is bounded by the length of the RRO
of the primary LSP. It can be made shorter by removing nodes by the of the primary LSP. It can be made shorter by removing nodes by the
ingress node and the ABRs. In the example above, the RRO of the ingress node and the ABRs. In the example above, the RRO of the pri-
primary LSP contains 8 subobjects, while the maximum XRO length can mary LSP contains 8 subobjects, while the maximum XRO length can be
be bounded by 6 subobjects (nodes A1 adn A2 do not have to be in the bounded by 6 subobjects (nodes A1 adn A2 do not have to be in the
XRO. For SRLG protection, the XRO has to list all SRLGs that are XRO. For SRLG protection, the XRO has to list all SRLGs that are
crossed by the primary LSP. crossed by the primary LSP.
15.2 Inter-AS LSP protection A.2 Inter-AS LSP protection
When an inter-AS LSP is established, which has to be protected by a When an inter-AS LSP is established, which has to be protected by a
backup LSP to provide link or node protection, the same method as for backup LSP to provide link or node protection, the same method as for
the inter-area LSP case can be used. The difference is when the the inter-area LSP case can be used. The difference is when the
backup LSP is not following the same AS-path as the primary LSP backup LSP is not following the same AS-path as the primary LSP
because then the XRO should always contain the full path of the pri- because then the XRO should always contain the full path of the pri-
mary LSP. In case the backup LSP is following the same AS-path (but mary LSP. In case the backup LSP is following the same AS-path (but
with different ASBRs - at least in case of node protection), it is with different ASBRs - at least in case of node protection), it is
much similar as the inter-area case: ASBRs expanding the ERO over the much similar as the inter-area case: ASBRs expanding the ERO over the
next AS may remove the XRO subobjects located in that AS. Note that next AS may remove the XRO subobjects located in that AS. Note that
skipping to change at page 19, line 45 skipping to change at page 20, line 43
XRO of the Path message of the detour LSP or bypass tunnel. The ASBR XRO of the Path message of the detour LSP or bypass tunnel. The ASBR
where the detour LSP or bypass tunnel is entering the AS can where the detour LSP or bypass tunnel is entering the AS can
translate this into the list of SRLG-ids known to the local AS. translate this into the list of SRLG-ids known to the local AS.
Discussion on the length of the XRO: the XRO only contains 1 subob- Discussion on the length of the XRO: the XRO only contains 1 subob-
ject, which contains the IP address of the inter-AS link traversed by ject, which contains the IP address of the inter-AS link traversed by
the primary LSP (in the assumption that the primary LSP and detour the primary LSP (in the assumption that the primary LSP and detour
LSP or bypass tunnel are leaving the AS in the same area, and they LSP or bypass tunnel are leaving the AS in the same area, and they
are also entering the next AS in the same area). are also entering the next AS in the same area).
15.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 [OVERLAY] (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
+----------+ | | +----------+ +----------+ | | +----------+
| +----+ | | +-----+ +-----+ +-----+ | | +----+ | | +----+ | | +-----+ +-----+ +-----+ | | +----+ |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
skipping to change at page 21, line 7 skipping to change at page 22, line 7
for instance CN5. When EN2 gets back the RRO of that LSP, it can sig- for instance CN5. When EN2 gets back the RRO of that LSP, it can sig-
nal a new LSP to CN1 with EN4 as destination and the XRO computed nal a new LSP to CN1 with EN4 as destination and the XRO computed
based on the RRO of the first LSP. Based on this information, CN1 can based on the RRO of the first LSP. Based on this information, CN1 can
compute a path that has the requested diversaty properties (e.g, a compute a path that has the requested diversaty properties (e.g, a
path going over CN2, CN3 and then to EN4). path going over CN2, CN3 and then to EN4).
It is clear that in these examples, the core-node may not edit the It is clear that in these examples, the core-node may not edit the
RRO in a Resv message such that it includes only the subobjects from RRO in a Resv message such that it includes only the subobjects from
the egress core-node through the egress edge-node. the egress core-node through the egress edge-node.
15.4 LSP protection inside a single area A.4 LSP protection inside a single area
The XRO can also be used inside a single area. Take for instance a The XRO can also be used inside a single area. Take for instance a
network where the TE extensions of the IGPs as described in [OSPF-TE] network where the TE extensions of the IGPs as described in [OSPF-TE]
and [ISIS-TE] are not used, and hence each node has to select a and [ISIS-TE] are not used, and hence each node has to select a
next-hop and possibly crankback [CRANKBACK] has to be used when there next-hop and possibly crankback [CRANKBACK] has to be used when there
is no viable next-hop. In this case, when signaling a backup LSP, the is no viable next-hop. In this case, when signaling a backup LSP, the
XRO can be put in the Path message to exclude the links, nodes or XRO can be put in the Path message to exclude the links, nodes or
SRLGs of the primary LSP. An alternative to provide this functional- SRLGs of the primary LSP. An alternative to provide this functional-
ity would be to indicate in the Path message of the backup LSP, the ity would be to indicate in the Path message of the backup LSP, the
primary LSP together witn an indication which type of protection is primary LSP together witn an indication which type of protection is
skipping to change at page 21, line 33 skipping to change at page 22, line 33
LSP. For SRLG protection, the XRO has to list all SRLGs that are LSP. For SRLG protection, the XRO has to list all SRLGs that are
crossed by the primary LSP. Note that for SRLG protection, the link crossed by the primary LSP. Note that for SRLG protection, the link
IP address to reference the SRLGs of that link cannot be used since IP address to reference the SRLGs of that link cannot be used since
the TE extensions of the IGPs are not used in this example, hence, a the TE extensions of the IGPs are not used in this example, hence, a
node cannot translate any link IP address located in that area to its node cannot translate any link IP address located in that area to its
SRLGs. SRLGs.
16. Full Copyright Statement 16. Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2002). All Rights Reserved.
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of develop- Internet organizations, except as needed for the purpose of develop-
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/