draft-ietf-ccamp-rsvp-te-exclude-route-03.txt   draft-ietf-ccamp-rsvp-te-exclude-route-04.txt 
Network Working Group CY. Lee Network Working Group CY. Lee
Internet-Draft Alcatel Internet-Draft Alcatel
Expires: August 22, 2005 A. Farrel Expires: January 18, 2006 A. Farrel
Old Dog Consulting Old Dog Consulting
S. De Cnodder S. De Cnodder
Alcatel Alcatel
February 18, 2005 July 17, 2005
Exclude Routes - Extension to RSVP-TE Exclude Routes - Extension to RSVP-TE
draft-ietf-ccamp-rsvp-te-exclude-route-03.txt draft-ietf-ccamp-rsvp-te-exclude-route-04.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions By submitting this Internet-Draft, each author represents that any
of Section 3 of RFC 3667. By submitting this Internet-Draft, each applicable patent or other IPR claims of which he or she is aware
author represents that any applicable patent or other IPR claims of have been or will be disclosed, and any of which he or she becomes
which he or she is aware have been or will be disclosed, and any of aware will be disclosed, in accordance with Section 6 of BCP 79.
which he or she 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 other groups may also distribute working documents as Internet-
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 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 August 22, 2005. This Internet-Draft will expire on January 18, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
The current RSVP-TE specification, "RSVP-TE: Extensions to RSVP for The RSVP-TE specification, "RSVP-TE: Extensions to RSVP for LSP
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
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.
Table of Contents Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4
1.1 Changes compared to version 01 . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1 Scope of Exclude Routes . . . . . . . . . . . . . . . . . 5 2.1 Scope of Exclude Routes . . . . . . . . . . . . . . . . . 6
2.2 Relationship to MPLS TE MIB . . . . . . . . . . . . . . . 7 2.2 Relationship to MPLS TE MIB . . . . . . . . . . . . . . . 7
3. Shared Risk Link Groups . . . . . . . . . . . . . . . . . . . 8 3. Shared Risk Link Groups . . . . . . . . . . . . . . . . . . . 8
3.1 SRLG ERO Subobject . . . . . . . . . . . . . . . . . . . . 8 3.1 SRLG ERO Subobject . . . . . . . . . . . . . . . . . . . . 8
4. Exclude Route List . . . . . . . . . . . . . . . . . . . . . . 9 4. Exclude Route List . . . . . . . . . . . . . . . . . . . . . . 10
4.1 Exclude Route Object (XRO) . . . . . . . . . . . . . . . . 9 4.1 Exclude Route Object (XRO) . . . . . . . . . . . . . . . . 10
4.1.1 Subobject 1: IPv4 prefix . . . . . . . . . . . . . . 10 4.1.1 IPv4 prefix Subobject . . . . . . . . . . . . . . . . 11
4.1.2 Subobject 2: IPv6 Prefix . . . . . . . . . . . . . . 11 4.1.2 IPv6 Prefix Subobject . . . . . . . . . . . . . . . . 12
4.1.3 Subobject 32: Autonomous System Number . . . . . . . 11 4.1.3 Unnumbered Interface ID Subobject . . . . . . . . . . 13
4.1.4 Subobject TBD: SRLG . . . . . . . . . . . . . . . . . 12 4.1.4 Autonomous System Number Subobject . . . . . . . . . . 14
4.1.5 Subobject 4: Unnumbered Interface ID Subobject . . . . 12 4.1.5 SRLG Subobject . . . . . . . . . . . . . . . . . . . . 15
4.2 Semantics and Processing Rules for the Exclude Route 4.2 Processing Rules for the Exclude Route Object (XRO) . . . 15
Object (XRO) . . . . . . . . . . . . . . . . . . . . . . . 13 5. Explicit Exclusion Route . . . . . . . . . . . . . . . . . . . 18
5. Explicit Exclude Route . . . . . . . . . . . . . . . . . . . . 16 5.1 Explicit Exclusion Route Subobject (EXRS) . . . . . . . . 18
5.1 Explicit Exclusion Route Subobject (EXRS) . . . . . . . . 16 5.2 Processing Rules for the Explicit Exclusion Route
5.2 Semantics and Processing Rules for the EXRS . . . . . . . 17 Subobject (EXRS) . . . . . . . . . . . . . . . . . . . . . 19
6. Minimum compliance . . . . . . . . . . . . . . . . . . . . . . 18 6. Processing of XRO together with EXRS . . . . . . . . . . . . . 21
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 7. Minimum compliance . . . . . . . . . . . . . . . . . . . . . . 22
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23
8.1 New Class Numbers . . . . . . . . . . . . . . . . . . . . 20 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
8.2 New Subobject Types . . . . . . . . . . . . . . . . . . . 20 9.1 New RSVP-TE Class Numbers . . . . . . . . . . . . . . . . 24
8.3 New Error Codes . . . . . . . . . . . . . . . . . . . . . 20 9.2 New ERO Subobject Type . . . . . . . . . . . . . . . . . . 24
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 9.3 New ERO and XRO Subobject Type . . . . . . . . . . . . . . 24
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 9.4 New Error Codes . . . . . . . . . . . . . . . . . . . . . 25
10.1 Normative References . . . . . . . . . . . . . . . . . . . 22 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 26
10.2 Informational References . . . . . . . . . . . . . . . . . 22 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23 11.1 Normative References . . . . . . . . . . . . . . . . . . . 27
A. applications . . . . . . . . . . . . . . . . . . . . . . . . . 24 11.2 Informational References . . . . . . . . . . . . . . . . . 27
A.1 Inter-area LSP protection . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 28
A.2 Inter-AS LSP protection . . . . . . . . . . . . . . . . . 25 A. applications . . . . . . . . . . . . . . . . . . . . . . . . . 29
A.3 Protection in the GMPLS overlay model . . . . . . . . . . 26 A.1 Inter-area LSP protection . . . . . . . . . . . . . . . . 29
A.4 LSP protection inside a single area . . . . . . . . . . . 28 A.2 Inter-AS LSP protection . . . . . . . . . . . . . . . . . 30
Intellectual Property and Copyright Statements . . . . . . . . 29 A.3 Protection in the GMPLS overlay model . . . . . . . . . . 31
A.4 LSP protection inside a single area . . . . . . . . . . . 33
Intellectual Property and Copyright Statements . . . . . . . . 34
1. Requirements notation 1. 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].
1.1 Changes compared to version 01
o References updated.
o Editorial updates.
o Added Unnumbered Interface exclusions
o Acknowledgements updated.
o IPR section.
o Appendix A with applications is added.
2. Introduction 2. Introduction
The current RSVP-TE specification [RFC3209] and GMPLS extensions The RSVP-TE specification [RFC3209] and GMPLS extensions [RFC3473]
[RFC3473] allow abstract nodes and resources to be explicitly allow abstract nodes and resources to be explicitly included in a
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.
Two types of exclusions are required: Two types of exclusions are required:
1. Exclude any of the abstract nodes in a given set anywhere on the 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. Exclude certain abstract nodes or resources between a specific
pair of abstract nodes present in an ERO. Such specific 2. Exclusion of certain abstract nodes or resources between a
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.
To convey these constructs within the signaling protocol, a new RSVP To convey these constructs within the signaling protocol, a new RSVP
object and a new ERO subobject are introcuded respectively. object and a new ERO subobject are introduced respectively.
1. A new RSVP-TE object is introduced to convey the Exclude Route 1. 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).
2. The second type of exclusion is achieved through a modification 2. 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 ERO subobject type the Explicit
Route Subobject (EXRS) is introduced to indicate an exclusion Exclusion Route Subobject (EXRS) is introduced to indicate an
between a pair of included abstract nodes. exclusion 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 [INTERAS-REQ], 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 of a path or between two abstract nodes specified in an whole path or between two abstract nodes specified in an explicit
explicit path. 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. signaled in either of the two exclusion methods described above and
This subobject might also be appropriate for use within Explicit this document does not assume or preclude any other usage for this
Routes or Record Routes, but that discussion is outside the scope of subobject. This subobject might also be appropriate for use within
Explicit Routes or Record Routes, but this is outside the scope of
this document. this document.
2.1 Scope of Exclude Routes 2.1 Scope of Exclude Routes
This document does not preclude a route exclusion from listing many This document does not preclude a route exclusion from listing
nodes or network elements to avoid. The intent is, however, to arbitrary nodes or network elements to avoid. The intent is,
indicate only the minimal number of subobjects to be avoided. For however, to indicate only the minimal number of subobjects to be
instance it may be necessary to signal only the SRLGs (or Shared avoided. For instance it may be necessary to signal only the SRLGs
Risk Groups) to avoid. (or Shared Risk Groups) to avoid.
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 20 skipping to change at page 6, line 25
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
or IGP sense, or may be an arbitrary division of the network for or IGP sense, or may be an arbitrary division of the network for
active management and path computational purposes. Let the primary active management and path computational purposes. Let the primary
path be (Ingress, A1, A2, AB1, B1, B2, BC1, C1, C2, Egress) where: path be (Ingress, A1, A2, AB1, B1, B2, BC1, C1, C2, Egress) where:
o Xn denotes a node in domain X, and o Xn denotes a node in domain X, and
o XYn denotes a node on the border of domain X and domain Y. o XYn denotes a node on the border of domain X and domain Y.
Note that Ingress is a node in domain A, and Egress is a node in Note that Ingress is a node in domain A, and Egress is a node in
domain C. This is shown in Figure 1 where the domains correspond domain C. This is shown in Figure 1 where the domains correspond with
with areas. areas.
area A area B area C area A area B area C
<-------------------> <----------------> <------------------> <-------------------> <---------------->
<------------------>
Ingress-----A1----A2----AB1----B1----B2----BC1----C1----C2----Egress Ingress-----A1----A2----AB1----B1----B2----BC1----C1----C2----Egress
^ \ / | \ / | \ / ^ \ / | \ / | \ /
| \ / | \ / | \ / | \ / | \ / | \ /
| A3----------A4--AB2--B3--------B4--BC2--C3----------C4 | A3----------A4--AB2--B3--------B4--BC2--C3----------C4
| ^ ^ | ^ ^
| | | | | |
| | ERO: (C3-strict, C4-strict, | | ERO: (C3-strict, C4-strict,
| | Egress-strict) | | Egress-strict)
| | XRO: Not needed | | XRO: Not needed
| | | |
| ERO: (B3-strict, B4-strict, BC2-strict, Egress-loose) | ERO: (B3-strict, B4-strict, BC2-strict, Egress-loose)
| XRO: (C1, C2) | XRO: (BC1, C1, C2)
| |
ERO: (A3-strict, A4-strict, AB2-strict, Egress-loose) ERO: (A3-strict, A4-strict, AB2-strict, Egress-loose)
XRO: (B1, B2, BC1, C1, C2, Egress) XRO: (AB1, B1, B2, BC1, C1, C2, Egress)
Consider the establishment of a node-diverse protection path in the Consider the establishment of a node-diverse protection path in the
example above. The protection path must avoid all nodes on the example above. The protection path must avoid all nodes on the
primary path. The exclusions for area A are handled during primary path. The exclusions for area A are handled during
Constrained Shortest Path First (CSPF) computation at Ingress, so the Constrained Shortest Path First (CSPF) computation at Ingress, so the
ERO and XRO signaled at Ingress could be (A3-strict, A4-strict, ERO and XRO signaled at Ingress could be (A3-strict, A4-strict, AB2-
AB2-strict, Egress-loose) and (B1, B2, BC1, C1, C2) respectively. At strict, Egress-loose) and (AB1, B1, B2, BC1, C1, C2) respectively.
AB2 the ERO and XRO could be (B3-strict, B4-strict, BC2-strict, At AB2 the ERO and XRO could be (B3-strict, B4-strict, BC2-strict,
Egress-loose) and (C1,C2) respectively. At BC2 the ERO could be Egress-loose) and (BC1, C1, C2) respectively. At BC2 the ERO could
(C3-strict, C4-strict, Egress-strict) and an XRO is not needed from be (C3-strict, C4-strict, Egress-strict) and an XRO is not needed
BC2 onwards. from BC2 onwards.
In general, consideration should be given (as with explicit route) to In general, consideration should be given (as with explicit route) to
the size of signaled data and the impact on the signaling protocol. the size of signaled data and the impact on the signaling protocol.
2.2 Relationship to MPLS TE MIB 2.2 Relationship to MPLS TE MIB
[RFC3812] defines managed objects for managing and modeling [RFC3812] defines managed objects for managing and modeling MPLS-
MPLS-based traffic engineering. Included in [RFC3812] is a means to based traffic engineering. Included in [RFC3812] is a means to
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.
3. Shared Risk Link Groups 3. 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]. RTG]. An SRLG ERO subobject is introduced such that it can be used
in the exclusion methods as described in the following sections.
This document does not assume or preclude any other usage for this
subobject. This subobject might also be appropriate for use within
Explicit Routes or Record Routes, but this is outside the scope of
this document.
3.1 SRLG ERO Subobject 3.1 SRLG ERO Subobject
The format of the ERO and its subobjects are defined in [RFC3209]. The format of the ERO and its subobjects are defined in [RFC3209].
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRLG Id (continued) | Reserved | | SRLG Id (continued) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 [TBD]. The type of the subobject [TBD by IANA].
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
Zero on transmission. Ignored on receipt This field is reserved. It MUST be set to zero on transmission
and MUST be ignored on receipt.
4. Exclude Route List 4. Exclude Route List
The exclude route identifies a list of abstract nodes that MUST 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 exlude route list to a value local
to the node originating the exclude route list. to the node originating the exclude route list.
4.1 Exclude Route Object (XRO) 4.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). The Exclude Route Class value is [TBD].
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, C_Type = 1 Class = TBD by IANA, C_Type = 1
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) //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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. The subobjects are identical to length data items called subobjects. This specification adapts ERO
those defined in [RFC3209] and [RFC3473] for use in EROs. subojbects as defined in [RFC3209], [RFC3473], and [RFC3477] for use
in route exclusions. The SRLG ERO subobject as defined in Section 3
of this document and its processing within ERO have not been defined
before. The SRLG ERO subobject is defined here for use 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 SRLG TBD SRLG
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 [RSPV-TE], 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 avoided (value
0) or SHOULD be avoided (value 1). 0) or SHOULD be avoided (value 1).
An Attribute octet is introduced in the subobjects that define IP Subobjects 1, 2, and 4 refer to an interface or a set of interfaces.
addresses to indicate the attribute (e.g. interface, node, SRLG) An Attribute octet is introduced in these subobjects to indicate the
associated with the IP addresses that can be excluded from the path. attribute (e.g. interface, node, SRLG) associated with the interfaces
For instance, the attribute node allows a whole node to be excluded that should be excluded from the path. For instance, the attribute
from the path, in contrast to the attribute interface, which allows node allows a whole node to be excluded from the path by specifying
specific interfaces to be excluded from the path. The attribute SRLG an interface of that node in the XRO subobject, in contrast to the
allows all SRLGs associated with an IP address to be excluded from attribute interface, which allows a specific interface (or multiple
the path. interfaces) to be excluded from the path without excluding the whole
nodes. The attribute SRLG allows all SRLGs associated with an
interface to be excluded from the path.
4.1.1 Subobject 1: IPv4 prefix 4.1.1 IPv4 prefix Subobject
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 | IPv4 address (4 bytes) | |L| Type | Length | IPv4 address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address (continued) | Prefix Length | Attribute | | IPv4 address (continued) | Prefix Length | Attribute |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 interface
0 indicates that the interface or set of interfaces associ- 0 indicates that the interface or set of interfaces
ated with the IP prefix should be excluded or avoided associated with the IPv4 prefix should be excluded or avoided
node node
1 indicates that the node or set of nodes associated with 1 indicates that the node or set of nodes associated with
the IP prefix should be excluded or avoided the IPv4 prefix should be excluded or avoided
SRLG SRLG
2 indicates that all the SRLGs associated with the IP 2 indicates that all the SRLGs associated with the IPv4
prefix should be excluded or avoided prefix should be excluded or avoided
The rest of the fields are as defined in [RFC3209]. The rest of the fields are as defined in [RFC3209].
4.1.2 Subobject 2: IPv6 Prefix 4.1.2 IPv6 Prefix Subobject
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) | Prefix Length | Attribute | | IPv6 address (continued) | Prefix Length | Attribute |
skipping to change at page 11, line 24 skipping to change at page 12, line 36
| 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 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 interface
0 indicates that the interface or set of interfaces associ- 0 indicates that the interface or set of interfaces associated
ated with the IP prefix should be excluded or avoided with the IPv6 prefix should be excluded or avoided
node node
1 indicates that the node or set of nodes associated with 1 indicates that the node or set of nodes associated with
the IP prefix should be excluded or avoided the IPv6 prefix should be excluded or avoided
SRLG SRLG
2 indicates that all the SRLG associated with the IP 2 indicates that all the SRLG associated with the IPv6
prefix should be excluded or avoided prefix should be excluded or avoided
The rest of the fields are as defined in [RFC3209]. The rest of the fields are as defined in [RFC3209].
4.1.3 Subobject 32: Autonomous System Number 4.1.3 Unnumbered Interface ID Subobject
The L bit of an Autonomous System Number subobject has meaning in an
Exclude Route (contrary to its usage in an Explict Route defined in
[RFC3209]. The meaning is as for other subobjects described above.
That is:
0 indicates that the abstract node specified MUST be excluded
1 indicates that the abstract node specified SHOULD be avoided
The rest of the fields are as defined in [RFC3209]. There is no
Attribute octet defined.
4.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
defined in the "SRLG ERO Subobject" section of this document.
4.1.5 Subobject 4: Unnumbered Interface ID Subobject
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 | Attribute | |L| Type | Length | Reserved | Attribute |
| | | |(must be zero) | | | | | |(must be zero) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 interface
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 node
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 subobjects from RRO, in specifying the convenient to use information from subobjects of an RRO
exclusions) as defined in [RFC3477], in specifying the exclusions).
SRLG SRLG
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
Zero on transmission. Ignored on receipt. This field is reserved. It MUST be set to zero on transmission
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].
4.2 Semantics and Processing Rules for the Exclude Route Object (XRO) 4.1.4 Autonomous System Number Subobject
The meaning of the L bit is as follows:
0 indicates that the abstract node specified MUST be excluded
1 indicates that the abstract node specified SHOULD be avoided
The rest of the fields are as defined in [RFC3209]. There is no
Attribute octet defined.
4.1.5 SRLG Subobject
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
defined in the "SRLG ERO Subobject" section of this document.
4.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, or an Autonomous System.
The Explicit Route and routing processing is unchanged from the The Explicit Route and routing processing is unchanged from the
skipping to change at page 13, line 50 skipping to change at page 16, line 5
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 should return a PathErr with error code sistent then the node should return 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 SHOULD not contradict each 3. The subobjects in the ERO and XRO MUST NOT contradict each other.
other. If they do contradict, the subobjects with the L flag not If a Path message is received that contains contradicting ERO and
set, strict or MUST be excluded, respectively, in the ERO or XRO XRO subobjects, then:
MUST take precedence. If there is still a conflict, a PathErr
with error code "Routing Problem" and error value of "Route * subobjects in the XRO with the L flag not set (zero) MUST take
blocked by Exclude Route" should be returned. precedence over the subobjects in the ERO - that is, a
mandatory exclusion expressed in the XRO MUST be honored and
an implementation MUST reject such a Path message. This means
that a PathErr with error code "Routing Problem" and error
value of "Route blocked by Exclude Route" is returned.
* subobjects in the XRO with the L flag set do not take
precedence over ERO subobjects - that is, an implementation
MAY choose to reject a Path message because of such a
contradiction, but MAY continue and set up the LSP (ignoring
the XRO subobjects contradicting the ERO subobjects).
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:
1. must not introduce an explicit node or an abstract node that 1. 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 exlicit nodes or abstract nodes with The number of introduced explicit nodes or abstract nodes
the L flag set to "avoid" should be minimised. with the L flag set to "avoid", which indicate that it is not
mandatory to be excluded but that it is less preferred,
should be minimised in the computed path.
2. must not introduce links, nodes or resources identified by 2. 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. minimised.
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
subob- jects. subobjects.
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 will forward it uninspected and will not apply the support the XRO, forward it uninspected and do not apply the
extensions to ERO processing described above. This makes the XRO a extensions to ERO processing described above. This approach is
'best effort' process. chosen to allow route exclusion to traverse parts of the network that
are not capable of parsing or handling the new function. Note that
This 'best-effort' approach is chosen to allow route exclusion to Record Route may be used to allow computing nodes to observe
traverse parts of the network that are not capable of parsing or violations of route exclusion and attempt to re-route the LSP
handling the new function. Note that Record Route may be used to accordingly.
allow computing nodes to observe violations of route exclusion and
attempt to re-route the LSP 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
that subobject, then that particular subobject is ignored. Examples that subobject, then that particular subobject is ignored. Examples
of a part of a subobject that can be supported are: (1) only prefix of a part of a subobject that can be supported are: (1) only prefix
32 of the IPv4 prefix subobject could be supported, or (2) a 32 of the IPv4 prefix subobject could be supported, or (2) a
particular subobject is supported but not the particular attribute particular subobject is supported but not the particular attribute
field. field.
When a node forwards a Path message, it can do the following three When a node forwards a Path message, it can do the following three
operations related to XRO besides of the processing rules mentioned operations related to XRO besides the processing rules mentioned
above: above:
1. If no XRO was present, an XRO may be included. 1. If no XRO was present, an XRO may be included.
2. If an XRO was present, it may remove the XRO if it is sure that 2. If an XRO was present, it may remove the XRO if it is sure that
the next nodes do not need this information anymore. An example the next nodes do not need this information anymore. An example
is where a node can expand the ERO to a full strict path towards is where a node can expand the ERO to a full strict path towards
the destination. See Figure 1 where BC2 is removing the XRO from the destination. See Figure 1 where BC2 is removing the XRO from
the Path message. the Path message.
3. If an XRO was present, the content of the XRO can be modified. 3. If an XRO was present, the content of the XRO can be modified.
Subobjects can be added or removed. See Figure 1 for an example Subobjects can be added or removed. See Figure 1 for an example
where AB2 is stripping off some subobjects. where AB2 is stripping off some subobjects.
5. Explicit Exclude Route In any case, a node MUST NOT introduce any explicit or abstract node
in the XRO (irrespective of the value of the L flag) that it also has
introduced in the ERO.
The Explicit Exclude Route defines abstract nodes or resources (such 5. Explicit Exclusion Route
as links, unnumbered interfaces or labels) that must not be used on
the path between two inclusive abstract nodes or resources in the The Explicit Exclusion Route defines abstract nodes or resources
explicit route. (such as links, unnumbered interfaces or labels) that must not or
should not be used on the path between two inclusive abstract nodes
or resources in the explicit route.
5.1 Explicit Exclusion Route Subobject (EXRS) 5.1 Explicit Exclusion Route Subobject (EXRS)
A new ERO subobject type is defined. The Explicit Exclude Route A new ERO subobject type is defined. The Explicit Exclusion Route
Subobject (EXRS) has type [TBD]. The EXRS may not be present in an Subobject (EXRS) has type [TBD by IANA]. Although the EXRS is an ERO
RRO or XRO. subobject and the XRO is reusing the ERO subobject, an EXRS MUST NOT
be present in an XRO. An EXRS is an ERO subobject, which contains
one or more subobjects in its own, called EXRS subobjects.
The format of the EXRS is as follows. The format of the EXRS is as follows:
0 1 0 1 2 3
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 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--------------//---------------+
|L| Type | Length | EXRS subobjects | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--------------//---------------+ |L| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// one or more EXRS subobjects //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L L
ignored and must be zero [Note: The L bit in an EXRS subobject It MUST be set to zero on transmission and MUST be ignored on
is as defined for the XRO subobjects] receipt. [Note: The L bit in an EXRS subobject is as defined
for the XRO subobjects]
Type Type
The type of the subobject, i.e. EXRS [TBD] The type of the subobject, i.e. EXRS [TBD by IANA]
EXRS subobjects Reserved
This field is reserved. It MUST be set to zero on transmission
and MUST be ignored on receipt.
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 an EXRS subobject is exactly the same
XRO subobject and may include an SRLG subobject. Both subob- as the format of a subobject in the XRO. An EXRS may include
jects are as described earlier in this document. all subobjects defined in this document for the XRO.
Thus, an EXRO subobject for an IP hop might 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length |L| Type | Length | |L| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address (4 bytes) | |L| Type | Length | IPv4 address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Attribute | Reserved | | IPv4 address (continued) | Prefix Length | Attribute |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note: The Most Significant Bit in the Type field could be used to
indicate exclusion of IPv4/IPv6, AS and SRLG subobjects, eliminating
the need to prepend the subobject with an additional TLV header.
This would reduce the number bytes require for each subobject by 2
bytes. However, this approach would reduce the ERO Type field space
by half. This issue need WG discussion and feedback.
5.2 Semantics and Processing Rules for the EXRS 5.2 Processing Rules for the Explicit Exclusion Route Subobject (EXRS)
Each EXRS may carry multiple exclusions. The exclusion is encoded Each EXRS may carry multiple exclusions. The exclusion is encoded
exactly as for XRO subobjects and prefixed by an additional Type and exactly as for XRO subobjects and prefixed by an additional Type and
Length. Length.
The scope of the exclusion is the step between the previous ERO The scope of the exclusion is the step between the previous ERO
subobject that identifies an abstract node, and the subsequent ERO subobject that identifies an abstract node, and the subsequent ERO
subobject that identifies an abstract node. Multiple exclusions may subobject that identifies an abstract node. The processing rules of
be present between any pair of abstract nodes. the EXRS are the same as the processing rule of the XRO within this
scope. Multiple exclusions may be present between any pair of
abstract nodes.
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 Exclusions may also indicate resources (such as unnumbered
interfaces, link ids, labels) that must not be used on the path to interfaces, link ids, labels) that must not be used on the path to
the next abstract node indicated in the ERO. the 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 abstract node in the ERO by the inclusion of an EXRS containing an
containing an SRLG subobject. If the L-bit value in the SRLG SRLG subobject. If the L-bit value in the SRLG subobject is zero,
subobject is zero, the resources (nodes, links, etc.) identified by the resources (nodes, links, etc.) identified by the SRLG MUST not be
the SRLG MUST not be used on the path to the next abstract node used on the path to the next abstract node indicated in the ERO. If
indicated in the ERO. If the L-bit is set, the resources identified the L-bit is set, the resources identified by the SRLG SHOULD be
by the SRLG SHOULD be avoided. avoided.
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
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
MUST take precedence.
If a node is called upon to process an EXRS and does not support If a node is called upon to process an EXRS and does not support
handling of exclusions it will return a PathErr with a "Bad handling of exclusions it will behave as described in [RFC3209] when
EXPLICIT_ROUTE object" error. an unrecognized ERO subobject is encountered. This means that this
node will return a PathErr with error code "Routing Error" and error
value "Bad Explicit Route Object" with the EXPLICIT_ROUTE object
inlcuded, truncated (on the left) to the offending EXRS.
If the presence of EXRO Subobjects precludes further forwarding of If the presence of EXRS precludes further forwarding of the Path
the Path message, the node should return a PathErr with the error message, the node should return a PathErr with the error code
code "Routing Problem" and error value of "Route blocked by Exclude "Routing Problem" and error value of "Route blocked by Exclude
Route". Route".
6. Minimum compliance 6. Processing of XRO together with EXRS
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,
links and resources listed in both places. Where some elements
appears in both lists it MUST be handled according to the stricter
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
should be avoided then the element MUST be excluded.
7. Minimum compliance
An implementation must be at least compliant with the following: An implementation must be at least compliant with the following:
1. The XRO MUST be supported with the following restrictions: 1. The XRO MUST be supported with the following restrictions:
* The IPv4 Prefix subobject MUST be supported with a prefix * The IPv4 Prefix subobject MUST be supported with a prefix
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 attriubute 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 SHOULD be supported. If supported, the same 2. The EXRS MAY be supported. If supported, the same restrictions
restrictions as for the XRO apply. as for the XRO apply.
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 8. 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 [RFC3209] and [RFC3473]. Note that any security concerns that above [RFC3209] and [RFC3473]. Note that any security concerns that
exist with Explicit Routes should be considered with regard to route exist with Explicit Routes should be considered with regard to route
exclusions. exclusions.
8. IANA Considerations 9. IANA Considerations
It might be considered that a possible approach would be to assign It might be considered that an alternative approach would be to
one of the bits of the ERO sub-object type field (perhaps the top assign one of the bits of the ERO sub-object type field (perhaps the
bit) to identify that a sub-object is intended for inclusion rather top bit) to identify that a sub-object is intended for inclusion
than exclusion. However, [RFC3209] states that the type field (seven rather than exclusion. However, [RFC3209] states that the type field
bits) should be assigned as 0 - 63 through IETF consensus action, 64 (seven bits) should be assigned as 0 - 63 through IETF consensus
- 95 as first come first served, and 96 - 127 are reserved for action, 64 - 95 as first come first served, and 96 - 127 are reserved
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 Class Numbers 9.1 New RSVP-TE Class Numbers
One new class number is required. One new class number is required for Exclude Route object (XRO)
defined in section "Exclude Route Object (XRO)".
EXCLUDE_ROUTE EXCLUDE_ROUTE
Class-Num = 011bbbbb Class-Num of type 11bbbbbb
CType: 1 Suggested value 232
8.2 New Subobject Types Defined CType: 1 (Exclude Route)
A new subobject type for the Exclude Route Object and Explicit Subobjects 1, 2, 4 and 32 as for Explicit Route Object.
Exclude Route Subobject is required. Additional SRLG subobject as requested in "New ERO and XRO
Subobject Type"
SRLG subobject 9.2 New ERO Subobject Type
A new subobject type for the ERO is required. The Explicit Exclusion Route subobject (EXRS) is defined in section
"Explicit Exclusion Route Subobject (EXRS)". This subobject may be
present in the Explicit Route Object, but not in the Route Record
Object, nor in the new Exclude Route Object.
Explicit Exclude Route subobject Suggested value 33
8.3 New Error Codes 9.3 New ERO and XRO Subobject Type
New error values are needed for the error code 'Routing Problem'. The SRLG subobject is defined in section "SRLG ERO Subobject". This
subobject may be present in the Exclude Route Object or in the
Explicit Route Object, but not in the Route Record Object.
Unsupported Exclude Route Subobject Type [TBD] Suggested value 34
Inconsistent Subobject [TBD]
Local Node in Exclude Route [TBD]
Route Blocked by Exclude Route [TBD]
9. Acknowledgments 9.4 New Error Codes
New error values are needed for the error code 'Routing Problem'
(24).
Unsupported Exclude Route Subobject Type Suggested value 64
Inconsistent Subobject Suggested value 65
Local Node in Exclude Route Suggested value 66
Route Blocked by Exclude Route Suggested value 67
10. 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!
10. References 11. References
10.1 Normative References 11.1 Normative References
[GMPLS-OSPF] [GMPLS-RTG]
Kompella, K. and Y. Rekhter, "OSPF Extensions in Support Kompella, K. and Y. Rekhter, "Routing Extensions in
of Generalized Multi-Protocol Label Switching", Support of Generalized Multi-Protocol Label Switching",
draft-ietf-ccamp-ospf-gmpls-extensions-12.txt, work in draft-ietf-ccamp-gmpls-routing-9.txt, work in progress,
progress, October 2003. October 2003.
[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.
10.2 Informational References 11.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-02.txt, work in Signaling", draft-ietf-ccamp-crankback-02.txt, work in
progress, July 2004. progress, July 2004.
[INTERAS] De Cnodder, S. and C. Pelsser, "Protection for inter-AS [INTERAS] De Cnodder, S. and C. Pelsser, "Protection for inter-AS
MPLS tunnels", MPLS tunnels",
draft-decnodder-ccamp-interas-protection-00.txt, work in draft-decnodder-ccamp-interas-protection-00.txt, work in
progress, July 2004. progress, July 2004.
[INTERAS-REQ] [INTERAS-REQ]
Zhang, R. and JP. Vasseur, "MPLS Inter-AS Traffic Zhang, R. and JP. Vasseur, "MPLS Inter-AS Traffic
Engineering requirements", Engineering requirements",
draft-ietf-tewg-interas-mpls-te-req-09.txt, work in draft-ietf-tewg-interas-mpls-te-req-09.txt, work in
progress, September 2004. progress, September 2004.
[MPLS-BUNDLE] [MPLS-BUNDLE]
Kompella, K., Rekhter, Y. and L. Berger, "Link Bundling in Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling
MPLS Traffic Engineering", in MPLS Traffic Engineering",
draft-ietf-mpls-bundle-04.txt, work in progress, July draft-ietf-mpls-bundle-04.txt, work in progress,
2002. July 2002.
[OVERLAY] Swallow, G., Drake, J., Ishimatsu, H. and Y. Rekhter, [OVERLAY] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter,
"GMPLS UNI: RSVP Support for the Overlay Model", "GMPLS UNI: RSVP Support for the Overlay Model",
draft-ietf-ccamp-gmpls-overlay-04.txt, work in progress, draft-ietf-ccamp-gmpls-overlay-04.txt, work in progress,
April 2004. April 2004.
[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, September (TE) Extensions to OSPF Version 2", RFC 3630,
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, June (TE) Management Information Base (MIB)", RFC 3812,
2004. June 2004.
Authors' Addresses Authors' Addresses
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
skipping to change at page 24, line 11 skipping to change at page 29, line 11
Phone: +32 3 240 85 15 Phone: +32 3 240 85 15
Email: stefaan.de_cnodder@alcatel.be Email: stefaan.de_cnodder@alcatel.be
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 a single object can be used
used for all the examples, hence making the XRO a rather generic for all the examples, hence making the XRO a rather generic object
object without having to define a solution and new objects for each without having to define a solution and new objects for each new
new application. application.
A.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 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 established 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 hops are con- figured, then the computed ERO at A could looks as
follows: (A1- strict, A2-strict, ABR1-strict, C-loose). When the follows: (A1- strict, A2-strict, ABR1-strict, C-loose). When the
skipping to change at page 25, line 32 skipping to change at page 30, line 32
if node protection and no link protection is required). When an ABR if node protection and no link protection is required). When an ABR
computes the next path segment, i.e. the path over the next area, it computes the next path segment, i.e. the path over the next area, it
may remove the nodes from the XRO that are located in that area with may remove the nodes from the XRO that are located in that area with
the exception of the ABR where the primary LSP is exiting the area. the exception of the ABR where the primary LSP is exiting the area.
The latter information is still required because when the selected The latter information is still required because when the selected
ABR (ABR4 in this example) further expands the ERO, it has to exclude ABR (ABR4 in this example) further expands the ERO, it has to exclude
the ABR on which the primary is entering that area (ABR3 in this the ABR on which the primary is entering that area (ABR3 in this
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 is a link between ABR4- ABR3
ABR3 and ABR3-C, then it is required to have ABR3 in the XRO gen- and ABR3-C, then it is required to have ABR3 in the XRO gen- erated
erated by ABR2. 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 pri- ingress node and the ABRs. In the example above, the RRO of the pri-
mary LSP contains 8 subobjects, while the maximum XRO length can be mary LSP contains 8 subobjects, while the maximum XRO length can be
bounded by 6 subobjects (nodes A1 adn A2 do not have to be in the bounded by 6 subobjects (nodes A1 and 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.
A.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 similar to the inter-area case: ASBRs expanding the ERO over the next
next AS may remove the XRO subobjects located in that AS. Note that AS may remove the XRO subobjects located in that AS. Note that this
this can only be done by ingress ASBRs (the ASBR where the LSP is can only be done by ingress ASBRs (the ASBR where the LSP is entering
entering the AS). the AS).
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. More details on the method of providing
SRLG protection for inter-AS LSPs can be found in [INTERAS]. SRLG protection for inter-AS LSPs can be found in [INTERAS].
Basically, the link IP address of the inter-AS link used by the Basically, the link IP address of the inter-AS link used by the
primary LSP is put into the XRO of the Path message of the detour LSP primary LSP is put into the XRO of the Path message of the detour LSP
or bypass tunnel. The ASBR where the detour LSP or bypass tunnel is or bypass tunnel. The ASBR where the detour LSP or bypass tunnel is
entering the AS can translate this into the list of SRLG-ids known to entering the AS can translate this into the list of SRLG-ids known to
the local AS. 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
ject, which contains the IP address of the inter-AS link traversed by subobject, which contains the IP address of the inter-AS link
the primary LSP (in the assumption that the primary LSP and detour traversed by the primary LSP (assuming that the primary LSP and
LSP or bypass tunnel are leaving the AS in the same area, and they detour LSP or bypass tunnel are leaving the AS in the same area, and
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 [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
+----------+ | | +----------+ +----------+ | | +----------+
| +----+ | | +-----+ +-----+ +-----+ | | +----+ | | +----+ | | +-----+ +-----+ +-----+ | | +----+ |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| --+ EN1+-+-----+--+ CN1 +---+ CN2 +---+ CN3 +---+-----+-+ EN3+-- | | --+ EN1+-+-----+--+ CN1 +---+ CN2 +---+ CN3 +---+-----+-+ EN3+-- |
| | | | +--+--+ | | | | +---+--+ | | | | | | | | +--+--+ | | | | +---+--+ | | | |
| +----+ | | | +--+--+ +--+--+ +--+--+ | | | +----+ | | +----+ | | | +--+--+ +--+--+ +--+--+ | | | +----+ |
| | | | | | | | | | | | | | | | | | | | | |
+----------+ | | | | | | | +----------+ +----------+ | | | | | | | +----------+
| | | | | | | | | | | | | |
+----------+ | | | | | | | +----------+ +----------+ | | | | | | | +----------+
skipping to change at page 27, line 25 skipping to change at page 32, line 26
| | | | | | | | | | | | | |
+----------+ | | | | | | | +----------+ +----------+ | | | | | | | +----------+
| | | | +--+--+ | +--+--+ | | | | | | | | +--+--+ | +--+--+ | | | |
| +----+ | | | | | +------+ | | | | +----+ | | +----+ | | | | | +------+ | | | | +----+ |
| | +-+--+ | | CN4 +-------------+ CN5 | | +--+-+ | | | | +-+--+ | | CN4 +-------------+ CN5 | | +--+-+ | |
| --+ EN2+-+-----+--+ | | +---+-----+-+ EN4+-- | | --+ EN2+-+-----+--+ | | +---+-----+-+ EN4+-- |
| | | | | +-----+ +-----+ | | | | | | | | | | +-----+ +-----+ | | | | |
| +----+ | | | | +----+ | | +----+ | | | | +----+ |
| | +--------------------------------+ | | | | +--------------------------------+ | |
+----------+ Core Network +----------+ +----------+ Core Network +----------+
Overlay Overlay Overlay Overlay
Network Network Network Network
Legend:
Legend: EN - Edge Node EN- Edge Node
CN - Core Node CN - Core Node
Figure A.2 Figure A.2
A first application is where an edge-node wants to establish multiple A first application is where an edge-node wants to establish multiple
LSPs towards the same destinatin edge-node, and these LSPs need to LSPs towards the same destination edge-node, and these LSPs need to
have as few or no SRLGs in common. In this case EN1 could establish have as few or no SRLGs in common. In this case EN1 could establish
an LSP towards EN3 and then it can establish a second LSP listing all an LSP towards EN3 and then it can establish a second LSP listing all
links used by the first LSP with the indicition to avoid the SRLGs of links used by the first LSP with the indication to avoid the SRLGs of
these links. This information can be used by CN1 to compute a path these links. This information can be used by CN1 to compute a path
for the second LSP. If the core network consists of multiple areas, for the second LSP. If the core network consists of multiple areas,
then the SRLG-ids have to be listed in the XRO. The same example then the SRLG-ids have to be listed in the XRO. The same example
applies to nodes and links. applies to nodes and links.
Another application is where the edge-node wants to set up a backup Another application is where the edge-node wants to set up a backup
LSP that is also protecting the links between the edge-nodes and LSP that is also protecting the links between the edge-nodes and
core-nodes. For instance, when EN2 establishes an LSP to EN4, it core-nodes. For instance, when EN2 establishes an LSP to EN4, it
sends a Path message to CN4, which computes a path towards EN4 over sends a Path message to CN4, which computes a path towards EN4 over
for instance CN5. When EN2 gets back the RRO of that LSP, it can 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 sig- 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 computed based on the RRO of the first LSP. Based on this
information, CN1 can compute a path that has the requested diversaty information, CN1 can compute a path that has the requested diversity
properties (e.g, a path going over CN2, CN3 and then to EN4). properties (e.g, a 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.
A.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 [RFC3630] network where the TE extensions of the IGPs as described in [RFC3630]
and [RFC3784] are not used, and hence each node has to select a and [RFC3784] are not used, and hence each node has to select a next-
next-hop and possibly crankback [CRANKBACK] has to be used when there hop and possibly crankback [CRANKBACK] has to be used when there is
is no viable next-hop. In this case, when signaling a backup LSP, no viable next-hop. In this case, when signaling a backup LSP, the
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
ity would be to indicate in the Path message of the backup LSP, the functionality would be to indicate in the Path message of the backup
primary LSP together witn an indication which type of protection is LSP, the primary LSP together with an indication which type of
required. This latter solution would work for link and node protec- protection is required. This latter solution would work for link and
tion, but not for SRLG protection. node protec- tion, but not for SRLG protection.
Discussion on the length of the XRO: when link or node protection is When link or node protection is requested, the XRO is of the same
requested, the XRO is of the same length as the RRO of the primary length as the RRO of the primary LSP. For SRLG protection, the XRO
LSP. For SRLG protection, the XRO has to list all SRLGs that are has to list all SRLGs that are crossed by the primary LSP. Note that
crossed by the primary LSP. Note that for SRLG protection, the link for SRLG protection, the link IP address to reference the SRLGs of
IP address to reference the SRLGs of that link cannot be used since that link cannot be used since the TE extensions of the IGPs are not
the TE extensions of the IGPs are not used in this example, hence, a used in this example. Hence, a node cannot translate any link IP
node cannot translate any link IP address located in that area to its address located in that area to its SRLGs.
SRLGs.
Intellectual Property Statement Intellectual Property Statement
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 Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
 End of changes. 

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