draft-ietf-ccamp-lsp-diversity-04.txt   draft-ietf-ccamp-lsp-diversity-05.txt 
CCAMP Working Group Zafar Ali, Ed. CCAMP Working Group Zafar Ali, Ed.
Internet Draft George Swallow, Ed. Internet Draft George Swallow, Ed.
Intended status: Standard Track Cisco Systems Intended status: Standard Track Cisco Systems
Expires: January 3, 2015 F. Zhang, Ed. Expires: April 26, 2015 F. Zhang, Ed.
Huawei Huawei
D. Beller, Ed. D. Beller, Ed.
Alcatel-Lucent Alcatel-Lucent
July 4, 2014 October 27, 2014
Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path
Diversity using Exclude Route Diversity using Exclude Route
draft-ietf-ccamp-lsp-diversity-04.txt draft-ietf-ccamp-lsp-diversity-05.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 3, 2015. This Internet-Draft will expire on April 26, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions This document is subject to BCP 78 and the IETF Trust's Legal Provisions
Relating to IETF Documents (http://trustee.ietf.org/license-info) Relating to IETF Documents (http://trustee.ietf.org/license-info)
in effect on the date of publication of this document. Please in effect on the date of publication of this document. Please
review these documents carefully, as they describe your rights review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License extracted from this document must include Simplified BSD License
text as described in Section 4.e of the Trust Legal Provisions text as described in Section 4.e of the Trust Legal Provisions
and are provided without warranty as described in the Simplified and are provided without warranty as described in the Simplified
BSD License. BSD License.
Internet Draft draft-ietf-ccamp-lsp-diversity-04.txt Internet Draft draft-ietf-ccamp-lsp-diversity-05.txt
Abstract Abstract
RFC 4874 specifies methods by which path exclusions may be RFC 4874 specifies methods by which path exclusions can be
communicated during RSVP-TE signaling in networks where precise communicated during RSVP-TE signaling in networks where precise
explicit paths are not computed by the LSP source node. This explicit paths are not computed by the LSP source node. This
document specifies procedures for additional route exclusion document specifies procedures for additional route exclusion
subobject based on Paths currently existing or expected to exist subobject based on Paths currently existing or expected to exist
within the network. within the network.
Conventions used in this document 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",
"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 RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Table of Contents Table of Contents
1. Introduction ............................................... 2 1. Introduction ..................................................2
1.1. Client Initiated Identifier ........................ 5 1.1. Client-Initiated Identifier ...........................5
1.2. PCE allocated Identifiers .......................... 6 1.2. PCE-allocated Identifier ..............................6
1.3. UNI-N allocated Identifiers ........................ 7 1.3. Network-Assigned Identifier ...........................7
2. RSVP-TE signaling extensions ............................... 9 2. RSVP-TE signaling extensions ..................................9
2.1. Diversity XRO Subobject ............................ 9 2.1. Diversity XRO Subobject ...............................9
2.1.1. Tunnel identifier TLVs ........................... 12 2.1.1. IPv4 Diversity XRO Subobject ....................9
2.1.2. Path Key TLVs .................................... 14 2.1.2. IPv6 Diversity XRO Subobject ...................14
2.1.3. Path Affinity Set TLVs ........................... 16 2.2. Processing rules for the Diversity XRO subobject .....17
2.2. Processing rules for the Diversity XRO subobject ... 19 2.3. Diversity EXRS Subobject .............................20
2.2.1. Processing rules for the tunnel identifier TLVs .. 20 3. Security Considerations ......................................22
2.2.2. Processing rules for the Path Key TLVs ........... 22 4. IANA Considerations ..........................................22
2.2.3. Processing rules for the PAS TLVs ................ 23 4.1. New XRO subobject types ..............................22
2.3. Diversity EXRS Subobject ........................... 25 4.2. New EXRS subobject types .............................23
3. Security Considerations .................................... 27 4.3. New RSVP error sub-codes .............................23
4. IANA Considerations ........................................ 27 5. Acknowledgements .............................................23
6. References ................................................. 28 6. References ...................................................24
6.1. Normative References ............................... 28 6.1. Normative References .................................24
6.2. Informative References ............................. 29 6.2. Informative References ...............................24
1. Introduction 1. Introduction
Path diversity for multiple connections is a well-known Service Path diversity for multiple connections is a well-known Service
Provider requirement. Diversity constraints ensure that Label- Provider requirement. Diversity constraints ensure that Label-
Switched Paths (LSPs) may be established without sharing Switched Paths (LSPs) can be established without sharing
Internet Draft draft-ietf-ccamp-lsp-diversity-04.txt
resources, thus greatly reducing the probability of simultaneous resources, thus greatly reducing the probability of simultaneous
connection failures. connection failures.
When a source node has full topological knowledge and is permitted When a source node has full topological knowledge and is permitted
to signal an Explicit Route Object (ERO), diverse paths can be to signal an Explicit Route Object, diverse paths for LSPs can be
computed locally. However, there are scenarios when path computed by this source node. However, there are scenarios when
computations are performed by remote nodes, thus there is a need for
relevant diversity constraints to be communicated to those nodes.
These include (but are not limited to):
. LSPs with loose hops in the ERO, e.g. inter-domain LSPs; Internet Draft draft-ietf-ccamp-lsp-diversity-05.txt
path computations are performed by different nodes, and there is
therefore a need for relevant diversity constraints to be
communicated to those nodes. These include (but are not limited
to):
. LSPs with loose hops in the Explicit Route Object (ERO), e.g.
inter-domain LSPs;
. Generalized Multi-Protocol Label Switching (GMPLS) User- . Generalized Multi-Protocol Label Switching (GMPLS) User-
Network Interface (UNI) where path computation may be performed Network Interface (UNI), where path computation may be
by the core node [RFC4208]. performed by the core node [RFC4208].
[RFC4874] introduced a means of specifying nodes and resources to [RFC4874] introduced a means of specifying nodes and resources to
be excluded from a route, using the eXclude Route Object (XRO) and be excluded from a route, using the eXclude Route Object (XRO) and
Explicit Exclusion Route Subobject (EXRS). It facilitates the Explicit Exclusion Route Subobject (EXRS). It facilitates the
calculation of diverse paths for LSPs based on known properties of calculation of diverse paths for LSPs based on known properties of
those paths including addresses of links and nodes traversed, and those paths including addresses of links and nodes traversed, and
Shared Risk Link Groups (SRLGs) of traversed links. Employing Shared Risk Link Groups (SRLGs) of traversed links. Employing
these mechanisms requires that the source node that initiates these mechanisms requires that the source node that initiates
signaling knows the relevant properties of the path(s) from which signaling knows the relevant properties of the path(s) from which
diversity is desired. However, there are circumstances under which diversity is desired. However, there are circumstances under which
this may not be possible or desirable, including (but not limited this may not be possible or desirable, including (but not limited
to): to):
. Exclusion of a path which does not originate, terminate or . Exclusion of a path which does not originate, terminate or
traverse the source node signaling the diverse LSP, in which traverse the source node of the diverse LSP, in which case the
case the addresses and SRLGs of the path from which diversity addresses of links and SRLGs of the path from which diversity
is required are unknown to the source node. is required are unknown to the source node.
. Exclusion of a path which is known to the source node of the . Exclusion of a path which is known to the source node of the
diverse LSP, however the node has incomplete or no path diverse LSP for which the node has incomplete or no path
information, e.g. due to policy. In other words, the scenario information, e.g. due to operator policy. In this case, the
in which the reference path is known by the source / requesting existence of the reference path is known to the source node but
node but the properties required to construct an XRO object are the information required to construct an XRO object to
not fully known. Inter-domain and GMPLS overlay networks can guarantee diversity from the reference path is not fully known.
present such restrictions. Inter-domain and GMPLS overlay networks can present such
restrictions.
This is exemplified in the Figure 1, where overlay reference This is exemplified in the Figure 1, where overlay reference
model from [RFC4208] is shown. model from [RFC4208] is shown.
Internet Draft draft-ietf-ccamp-lsp-diversity-04.txt Internet Draft draft-ietf-ccamp-lsp-diversity-05.txt
Overlay Overlay
Network +----------------------------------+ Network Overlay Overlay
+---------+ | | +---------+ Network +----------------------------------+ Network
| +----+ | | +-----+ +-----+ +-----+ | | +----+ | +---------+ | | +---------+
| | | | UNI | | | | | | | | UNI | | | | | +----+ | | +-----+ +-----+ +-----+ | | +----+ |
| -+ EN1+-+-----+--+ CN1 +----+ CN2 +----+ CN3 +---+-----+-+ EN3+- | | | | | UNI | | | | | | | | UNI | | | |
| | | | +--+--+ | | | | | | +---+-| | | | -+ EN1+-+-----+--+ CN1 +----+ CN2 +----+ CN3 +---+-----+-+ EN3+- |
| +----+ | | | +--+--+ +--+--+ +--+--+ | | | +----+ | | | | | +--+--+ | | | | | | +---+-| | |
+---------+ | | | | | | | +---------+ | +----+ | | | +--+--+ +--+--+ +--+--+ | | | +----+ |
| | | | | | | +---------+ | | | | | | | +---------+
+---------+ | | +--+--+ | +--+--+ | | +---------+ | | | | | | |
| +----+ | | | | | +-------+ +-----+ | +----+ | +---------+ | | +--+--+ | +--+--+ | | +---------+
| | +-+--+ | | CN4 +---------------+ CN5 | | | | | | | +----+ | | | | | +-------+ +-----+ | +----+ |
| -+ EN2+-+-----+--+ | | +---+-----+-+ EN4+- | | | +-+--+ | | CN4 +---------------+ CN5 | | | | | |
| | | | UNI | +-----+ +-----+ | UNI | | | | | -+ EN2+-+-----+--+ | | +---+-----+-+ EN4+- |
| +----+ | | | | +----+ | | | | | UNI | +-----+ +-----+ | UNI | | | |
+---------+ +----------------------------------+ +---------+ | +----+ | | | | +----+ |
Overlay Core Network Overlay +---------+ +----------------------------------+ +---------+
Network Network Overlay Core Network Overlay
Network Network
Legend: EN - Edge Node Legend: EN - Edge Node
CN - Core Node CN - Core Node
Figure 1: Overlay Reference Model [RFC4208] Figure 1: Overlay Reference Model [RFC4208]
Figure 1 depicts two types of UNI connectivity: single-homed and Figure 1 depicts two types of UNI connectivity: single-homed and
dual-homed ENs (which also applies to higher order multi-homed dual-homed ENs (which also applies to higher order multi-homed
connectivity.). Single-homed Edge Node (EN) devices are connected connectivity.). Single-homed EN devices are connected to a single
to a single Core Node (CN) device via a single UNI link. This CN device via a single UNI link. This single UNI link may
single UNI link may constitute a single point of failure. UNI constitute a single point of failure. UNI connection between EN1
connection between EN1 and CN1 is an example of singled-homed UNI and CN1 is an example of singled-homed UNI connectivity.
connectivity.
A single point of failure caused by a single-homed UNI can be A single point of failure caused by a single-homed UNI can be
avoided when the EN device is connected to two different CN avoided when the EN device is connected to two different CN
devices, as depicted for EN2 in Figure 1. For the dual-homing devices, as depicted for EN2 in Figure 1. For the dual-homing
case, it is possible to establish two different UNI connections case, it is possible to establish two different UNI connections
from the same source EN device to the same destination EN device. from the same source EN device to the same destination EN device.
For example, two connections from EN2 to EN3 may use the two UNI For example, two connections from EN2 to EN3 may use the two UNI
links EN2-CN1 and EN2-CN4. To avoid single points of failure links EN2-CN1 and EN2-CN4. To avoid single points of failure
within the provider network, it is necessary to also ensure path within the provider network, it is necessary to also ensure path
(LSP) diversity within the core network. (LSP) diversity within the core network.
In Figure 1, the CNs typically performs path computation. In a UNI network such as that shown in Figure 1, the CNs
Information sharing across the UNI boundary is restricted based typically perform path computation. Information sharing across
on the policy rules imposed by the core network. Typically, the
Internet Draft draft-ietf-ccamp-lsp-diversity-04.txt Internet Draft draft-ietf-ccamp-lsp-diversity-05.txt
core network topology information is not exposed to the ENs. In the UNI boundary is restricted based on the policy rules imposed
such networks, consider a use case where an LSP from EN2 to EN4 by the core network. Typically, the core network topology
needs to be SRLG diverse from an LSP from EN1 to EN3. In this information is not exposed to the ENs. In the network shown in
case, EN2 may not know SRLG attributes of the EN1- EN3 LSP and Figure 1, consider a use case where an LSP from EN2 to EN4 needs
hence cannot construct an XRO to exclude these SRLGs. In this to be SRLG diverse from an LSP from EN1 to EN3. In this case, EN2
example EN2 cannot use procedures described in [RFC4874]. may not know SRLG attributes of the EN1- EN3 LSP and hence cannot
Similarly, in the context of dual-homed UNI example described construct an XRO to exclude these SRLGs. In this example EN2
above, an LSP from EN2 to EN3 going via CN1 needs to be diverse cannot use the procedures described in [RFC4874]. Similarly, an
from an LSP from EN2 to EN3 going via CN4. Again in this case, LSP from EN2 to EN3 traversing CN1 needs to be diverse from an
[RFC4874] based exclusions cannot be used. LSP from EN2 to EN3 going via CN4. Again in this case, exclusions
based on [RFC4874] cannot be used.
This document addresses these diversity requirements by This document addresses these diversity requirements by
introducing the notion of excluding the path taken by particular introducing the notion of excluding the path taken by particular
LSP(s). The reference LSP(s) with which diversity is required is LSP(s). The reference LSP(s) or route(s) from which diversity is
identified by an "identifier". The type of identifier to use is required is/are identified by an "identifier". The type of
highly dependent on the networking deployment scenario. For identifier to use is highly dependent on the networking
example, if the identifier is client initiated, the network deployment scenario; it could be client-initiated, allocated by
allocates identifier or a Path Computation Element (PCE) manages the (core) network or managed by a PCE. This document defines
identifier. Consequently, this document defines three different three different types of identifiers corresponding to these three
types of identifiers: client initiated identifier, PCE allocated cases: a client initiated identifier, a PCE allocated Identifier
Identifier and network allocated Identifier, as detailed in the and CN ingress node (UNI-N) allocated Identifier.
following sections.
1.1. Client Initiated Identifier 1.1. Client-Initiated Identifier
There are scenarios in which the ENs have the following There are scenarios in which the ENs have the following
requirements for the diversity identifier: requirements for the diversity identifier:
- The identifier is controller by the client side and is - The identifier is controlled by the client side and is
specified as part of the service request. specified as part of the service request.
- Both client and server should understand the identifier. - Both client and server understand the identifier.
- The identifier needs to be reference able even if the LSP - It is necessary to be able to reference the identifier even if
referenced by it is not yet signaled. the LSP referenced by it is not yet signaled.
- The identifier should be stable for a long period of time. - The identifier is to be stable for a long period of time.
- The identifier should be stable even when the tunnel is - The identifier is to be stable even when the referenced tunnel
rerouted. is rerouted.
- The identifier should be human readable. - The identifier is to be human-readable.
The above-mentioned requirements are met by using RSVP tunnel/ These requirements are met by using the Resource ReserVation
LSP Forwarding Equivalence Class (FEC) as the identifier. Protocol (RSVP) tunnel/ LSP Forwarding Equivalence Class (FEC) as
Consequently, RSVP tunnel/ LSP FEC is used as client initiated the identifier.
identifier.
Internet Draft draft-ietf-ccamp-lsp-diversity-04.txt Internet Draft draft-ietf-ccamp-lsp-diversity-05.txt
The usage of the client-initiated identifier is illustrated by The usage of the client-initiated identifier is illustrated by
using Figure 1. Suppose a tunnel from EN2 to EN4 needs to be using Figure 1. Suppose a tunnel from EN2 to EN4 needs to be
diverse with respect to a tunnel from EN1 to EN3. Lets assume diverse with respect to a tunnel from EN1 to EN3. The tunnel FEC
tunnel FEC of the EN1-EN3 tunnel is FEC1, where FEC1 is defined of the EN1-EN3 tunnel is FEC1, where FEC1 is defined by the tuple
by the tuple (tunnel-id = T1, source address = EN1.ROUTE (tunnel-id = T1, source address = EN1.ROUTE Identifier (RID),
Identifier (RID), destination address = EN3.RID, extended tunnel- destination address = EN3.RID, extended tunnel-id = EN1.RID).
id = EN1.RID). Similarly, tunnel FEC of the EN2-EN3 tunnel is Similarly, tunnel FEC of the EN2-EN3 tunnel is FEC2, where FEC2
FEC2, where FEC2 is defined by the tuple (tunnel-id = T2, source is defined by the tuple (tunnel-id = T2, source address =
address = EN2.RID, destination address = EN4.RID, extended EN2.RID, destination address = EN4.RID, extended tunnel-id =
tunnel-id = EN2.RID). EN1-EN3 tunnel is signaled such that it EN2.RID). The EN1-EN3 tunnel is signaled with an exclusion
specifies the exclusion requirement from FEC2. Similarly, EN2-EN3 requirement from FEC2, and the EN2-EN3 tunnel is signaled with an
tunnel is signaled such that it specifies the exclusion exclusion requirement from FEC1. In order to maintain diversity
requirement from FEC1. In order to maintain diversity between between these two connections within the core network, it is
these two connections within the core network, it is assumed that assumed that the core network implements Crankback Signaling
the core network implements Crank back Signaling [RFC4920]. [RFC4920]. Note that crankback signaling is known to lead to
Similarly, diversity within the core network for a dual homed UNI slower setup times and sub-optimal paths under some circumstances
case is satisfied by the use of Crank back Signaling [RFC4920]. as described by [RFC4920].
1.2. PCE allocated Identifiers 1.2. PCE-allocated Identifier
In scenarios where a PCE is deployed and used to perform path In scenarios where a PCE is deployed and used to perform path
computation, the core edge node (e.g., node CN1 in Figure 1) computation, the core edge node (e.g., node CN1 in Figure 1)
could consult a PCE to allocate identifiers, which are used to could consult a PCE to allocate identifiers, which are used to
signal path diversity constraints. In other scenarios a PCE is signal path diversity constraints. In other scenarios a PCE is
deployed in each border node or a PCE is part of the Network deployed in each border node or a PCE is part of a Network
Management System (NMS). In all these cases, the Path key as Management System (NMS). In all these cases, the Path Key as
defined in [RFC5520] can be used in RSVP signaling as the defined in [RFC5520] can be used in RSVP signaling as the
identifier to ensure diversity. identifier to ensure diversity.
The usage of specifying LSP diversity using Path Key is An example of specifying LSP diversity using a Path Key is shown
exemplified in Figure 2, where a simple network with two domains in Figure 2, where a simple network with two domains is shown. It
is shown. It is desired to set up a pair of path-disjoint LSPs is desired to set up a pair of path-disjoint LSPs from the source
from the source in Domain 1 to the destination in Domain 2, but in Domain 1 to the destination in Domain 2, but the domains keep
the domains keep strict confidentiality about all path and strict confidentiality about all path and topology information.
topology information.
The first LSP is signaled by the source with ERO {A, B, loose Dst} The first LSP is signaled by the source with ERO {A, B, loose Dst}
and is set up with the path {Src, A, B, U, V, W, Dst}. However, and is set up with the path {Src, A, B, U, V, W, Dst}. However,
when sending the RRO out of Domain 2, node U would normally strip when sending the RRO out of Domain 2, node U would normally strip
the path and replace it with a loose hop to the destination. With the path and replace it with a loose hop to the destination. With
this limited information, the source is unable to include enough this limited information, the source is unable to include enough
detail in the ERO of the second LSP to avoid it taking, for detail in the ERO of the second LSP to avoid it taking, for
example, the path {Src, C, D, X, V, W, Dst} for path-disjointness. example, the path {Src, C, D, X, V, W, Dst} for path-disjointness.
Internet Draft draft-ietf-ccamp-lsp-diversity-04.txt Internet Draft draft-ietf-ccamp-lsp-diversity-05.txt
--------------------- ----------------------------- --------------------- -----------------------------
| Domain 1 | | Domain 2 | | Domain 1 | | Domain 2 |
| | | | | | | |
| --- --- | | --- --- --- | | --- --- | | --- --- --- |
| | A |--| B |--+--+--| U |--| V |---| W | | | | A |--| B |--+--+--| U |--| V |---| W | |
| / --- --- | | --- --- --- \ | | / --- --- | | --- --- --- \ |
| ---/ | | / / \--- | | ---/ | | / / \--- |
| |Src| | | / / |Dst| | | |Src| | | / / |Dst| |
| ---\ | | / / /--- | | ---\ | | / / /--- |
| \ --- --- | | --- / --- / --- / | | \ --- --- | | --- / --- / --- / |
| | C |--| D |--+--+--| X |---| Y |--| Z | | | | C |--| D |--+--+--| X |---| Y |--| Z | |
| --- --- | | --- --- --- | | --- --- | | --- --- --- |
| | | | | | | |
--------------------- ----------------------------- --------------------- -----------------------------
Figure 2: A Simple Multi-Domain Network Figure 1: A Simple Multi-Domain Network
In order to improve the situation, node U performs the PCE In order to improve the situation, node U performs the PCE
function and replaces the path segment {U, V, W} in the RRO with function and replaces the path segment {U, V, W} in the RRO with
a Path Key Subobject [RFC5553]. The Path Key Subobject assigns an a Path Key Subobject. The Path Key Subobject assigns an
"identifier" to the key. The PCE ID in the message indicates that "identifier" to the key. The PCE ID in the message indicates that
it was node U that made the replacement. it was node U that made the replacement.
With this additional information, the source is able to signal With this additional information, the source is able to signal
the subsequent LSPs with the ERO set to {C, D, exclude Path the subsequent LSPs with the ERO set to {C, D, exclude Path
Key(EXRS), loose Dst}. When the signaling message reaches node X, Key(EXRS), loose Dst}. When the signaling message reaches node X,
it can consult node U to expand the Path Key and know how to it can consult node U to expand the Path Key and know how to
avoid the path of the first LSP. Alternatively, the source could avoid the path of the first LSP. Alternatively, the source could
use an ERO of {C, D, loose Dst} and include an XRO containing the use an ERO of {C, D, loose Dst} and include an XRO containing the
Path Key. Path Key.
1.3. Network allocated Identifiers This mechanism can work with all the Path-Key resolution
mechanisms, as detailed in [RFC5553] section 3.1. A PCE, co-
There are scenarios in which the network provides diversity located or not, may be used to resolve the Path-Key, but the node
information for a service that allows the client device to (i.e., a Label Switching Router (LSR)) can also use the Path Key
include this information in the signaling message. In this information to index a Path Segment previously supplied to it by
section two signaling approaches are outlined that use network the entity that originated the Path-Key, for example the LSR that
allocated identifiers. While both methods could be implemented in inserted the Path-Key in the RRO or a management system.
the same core network, it is very likely that a core network
supports only one of the two mechanisms.
The first method assumes that core network Shared Resource Link 1.3. Network-Assigned Identifier
Group (SRLG) identifier information is both available and
shareable (by policy) with the ENs. In this case, the procedure
defined in [DRAFT-SRLG-RECORDING] can be used to collect SRLG
identifiers associated with an LSP (say LSP1). Suppose that LSP2
Internet Draft draft-ietf-ccamp-lsp-diversity-04.txt There are scenarios in which the network provides diversity-
related information for a service that allows the client device
to include this information in the signaling message. If the
Shared Resource Link Group (SRLG) identifier information is both
available and shareable (by policy) with the ENs, the procedure
needs to be diverse with respect to LSP1. When the EN constructs Internet Draft draft-ietf-ccamp-lsp-diversity-05.txt
the RSVP signaling message for setting up LSP2, it can insert the
SRLG identifiers associated with LSP1 as diversity constraints
into the XRO using the procedure described in [RFC4874]. This
method is not discussed further as it utilizes existing RSVP
protocol mechanisms for collecting SRLG information and passing
this diversity information to the CN.
The second method assumes that core network SRLG identifiers are defined in [DRAFT-SRLG-RECORDING] can be used to collect SRLG
identifiers associated with an LSP (LSP1). When a second LSP
(LSP2) needs to be diverse with respect to LSP1, the EN
constructing the RSVP signaling message for setting up LSP2 can
insert the SRLG identifiers associated with LSP1 as diversity
constraints into the XRO using the procedure described in
[RFC4874]. However, if the core network SRLG identifiers are
either not available or not shareable with the ENs based on either not available or not shareable with the ENs based on
policies enforced by core network. In this case, a signaling policies enforced by core network, existing mechanisms cannot be
mechanism is defined where information signaled to the CN via the used.
UNI does not require shared knowledge of provider SRLG
information. For this purpose, notion of Path Affinity Set (PAS)
is used for abstracting SRLG information. The motive behind the
PAS information is to have as little exchange of diversity
information as possible between the core network (CNs) and the
client devices (ENs). I.e., rather than a detailed SRLG list, the
PAS contains an abstract SRLG identifier associated with a given
path.
There are two types of diversity information in the PAS. The In this draft, a signaling mechanism is defined where information
first type of information is a single PAS identifier. The Second signaled to the CN via the UNI does not require shared knowledge
part is the optional PATH information, in the form of Source and of core network SRLG information. For this purpose, the concept
Destination addresses of a path. This mechanism can also be of a Path Affinity Set (PAS) is used for abstracting SRLG
applied to L1 VPNs and in this particular case, the identifier information. The motive behind the introduction of the PAS is to
only needs to be unique within the scope of a particular VPN. minimize the exchange of diversity information between the core
network (CNs) and the client devices (ENs). The PAS contains an
abstract SRLG identifier associated with a given path rather than
a detailed SRLG list. The PAS is a single identifier that can be
used to request diversity and associate diversity. The means by
which the processing node determines the path corresponding to
the PAS is beyond the scope of this document.
A CN on the core network boundary interprets the specific PAS A CN on the core network boundary interprets the specific PAS
identifier, for example, "123" as meaning to exclude the core identifier (e.g. "123") as meaning to exclude the core network
network SRLG information (or equivalent) that has been allocated SRLG information (or equivalent) that has been allocated by LSPs
by LSPs associated with this PAS identifier value. For example, associated with this PAS identifier value. For example, if a Path
if a Path exists for the LSP with the identifier "123", the CN exists for the LSP with the identifier "123", the CN would use
would use local knowledge of the core network SRLGs associated local knowledge of the core network SRLGs associated with the
with the "123" LSPs and use those SRLGs as constraints for path "123" LSPs and use those SRLGs as constraints for path
computation. In other words, two LSPs that need to be diverse computation. If a PAS identifier is included for exclusion in the
both signal "123" and the CNs interpret this as meaning not to connection request, the CN (UNI-N) in the core network is assumed
use shared resources. Alternatively, a CN could use the PAS to be able to determine the existing core network SRLG
identifier to select from already established LSPs. Once the path information and calculate a path that meets the determined
is established core network allocated the "123" identifier or diversity constraints.
optionally another PAS identifier for that VPN that replaces
"123".
The optional PAS source and destination address tuple represents
one or more source addresses and destination addresses associated
with the EN PAS identifier. These associated address tuples
represent paths that use resources that should be excluded for
Internet Draft draft-ietf-ccamp-lsp-diversity-04.txt When a CN satisfies a connection setup for a (SRLG) diverse
signaled path, the CN may optionally record the core network SRLG
information for that connection in terms of CN based parameters
and associates that with the EN addresses in the Path message.
Specifically for Layer-1 Virtual Private Networks (L1VPNs), Port
Information Tables (PIT) [RFC5251] can be leveraged to translate
between client (EN) addresses and core network addresses.
the establishment of the current LSP. The address tuple The PAS and the associated SRLG information can be distributed
information gives both finer grain details on the path diversity within the core network by an Interior Gateway Protocol (IGP) or
request and serves as an alternative identifier in the case when
the PAS identifier is not known by the CN. The address tuples
used in signaling is within a client network context and its
interpretation is local to a CN that receives a Path request from
an EN. The CN can use the address information to relate to CN
addresses and core network SRLG information. When a CN satisfies
a connection setup for a (SRLG) diverse signaled path, the CN may
optionally record the core network SRLG information for that
connection in terms of CN based parameters and associates that
with the EN addresses in the Path message. Specifically for
L1VPNs, Port Information tables (PIT) [RFC5251] can be leveraged
to translate between client (EN) based addresses and core network
based addresses. The PAS and associated core network addresses
with core network SRLG information can be distributed via the IGP
in the core network (or by other means such as configuration);
they can be utilized by other CNs when other ENs are requesting
paths to be setup that would require path/connection diversity.
In the VPN case, this information is distributed on a VPN basis
and contains a PAS identifier, CN addresses and SRLG information.
If diversity is not signaled, the assumption is that no diversity Internet Draft draft-ietf-ccamp-lsp-diversity-05.txt
is required and the core network is free to route the LSP to
optimize traffic. No Path affinity set information needs to be
recorded for these LSPs. If a diversity object is included in
the connection request, the CN in the core network should be able
to determine (look-up) the existing core network SRLG information
and choose an LSP that is maximally diverse from other LSPs.
The Path Affinity Set identifier is independent of the mechanism by other means such as configuration. They can then be utilized
the EN or the CN use for diversity. The Path Affinity Set is a by other CNs when other ENs are requesting paths to be setup that
single identifier that can be used to request diversity and would require path/connection diversity. In the VPN case, this
associate diversity. information is distributed on a VPN basis and contains a PAS
identifier, CN addresses and SRLG information. In this way, on a
VPN basis, the core network can have additional opaque records
for the PAS values for various Paths along with the SRLG list
associated with the Path. This information is internal to the
core network and is known only to the core network.
2. RSVP-TE signaling extensions 2. RSVP-TE signaling extensions
This section describes the signaling extensions required to This section describes the signaling extensions required to
address the aforementioned requirements and use cases. address the aforementioned requirements and use cases.
2.1. Diversity XRO Subobject 2.1. Diversity XRO Subobject
New Diversity XRO subobjects are defined by this document as New Diversity XRO subobjects are defined by this document as
follows. follows.
Internet Draft draft-ietf-ccamp-lsp-diversity-04.txt 2.1.1. IPv4 Diversity XRO 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 |Attribute Flags|Exclusion Flags| Reserved | |L| XRO Type | Length |DI Type|A-Flags|E-Flags| Resvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLVs ... | | IPv4 Diversity Identifier source address |
// // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Diversity Identifier Value |
// ... //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L: L:
The L-flag is used as for the XRO subobjects defined in The L-flag is used as for the XRO subobjects defined in
[RFC4874], i.e., [RFC4874], i.e.,
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.
Type Internet Draft draft-ietf-ccamp-lsp-diversity-05.txt
Type for diversity XRO subobject (to be assigned by IANA; XRO Type
suggested value: 37).
Attribute Flags: Type for IPv4 diversity XRO subobject (to be assigned by
IANA; suggested value: 37).
The Attribute Flags are used to communicate desirable Length
attributes of the LSP being signaled. The following flags
are defined. Each flag acts independently. Any combination The Length contains the total length of the subobject in
of flags is permitted. bytes, including the Type and Length fields. The Length is
variable, depending on the diversity identifier value.
Diversity Identifier Type (DI Type)
Diversity Identifier Type (DI Type) indicates the way the
reference LSP(s) or route(s) with which diversity is
required is identified. Three values are defined in this
document:
IPv4 Client Initiated Identifier 1 (to be assigned by
IANA)
IPv4 PCE Allocated Identifier 2 (to be assigned by
IANA)
IPv4 Network Assigned Identifier 3 (to be assigned by
IANA)
Attribute Flags (A-Flags):
The Attribute Flags (A-Flags) are used to communicate
desirable attributes of the LSP being signaled. The
following flags are defined. Each flag acts independently.
Any combination of flags is permitted.
0x01 = Destination node exception 0x01 = Destination node exception
Indicates that exclusion does not apply to the Indicates that the exclusion does not apply to the
destination node of the LSP being signaled. destination node of the LSP being signaled.
0x02 = Processing node exception 0x02 = Processing node exception
Indicates that exclusion does not apply to the border Indicates that the exclusion does not apply to the
node(s) performing ERO expansion for the LSP being border node(s) performing ERO expansion for the LSP
signaled. Ingress UNI-N node is an example of such being signaled. An ingress UNI-N node is an example of
nodes. such a node.
0x04 = Penultimate node exception Internet Draft draft-ietf-ccamp-lsp-diversity-05.txt
Internet Draft draft-ietf-ccamp-lsp-diversity-04.txt 0x04 = Penultimate node exception
Indicates that the penultimate node of the LSP being Indicates that the penultimate node of the LSP being
signaled MAY be shared with the excluded path even when signaled MAY be shared with the excluded path even when
this violates the exclusion flags. this violates the exclusion flags.
0x08 = LSP ID to be ignored 0x08 = LSP ID to be ignored
This flag is only applicable to the IPv4/ IPv6 Point-to- This flag is only applicable when the diversity is
Point tunnel identifier TLVs of the Diversity XRO specified using the client-initiated identifier, the
subobjects defined in section 2.1.1. In this context, flag indicates tunnel level exclusion, as detailed in
the flag indicates tunnel level exclusion. Specifically, section 2.2.
this flag is used to indicate that the lsp-id field of
the IPv4/ IPv6 Point-to-Point tunnel identifier TLVs is
to be ignored and the exclusion applies to any LSP
matching the rest of the supplied FEC.
Exclusion Flags Exclusion Flags (E-Flags):
The Exclusion-Flags are used to communicate the desired The Exclusion-Flags are used to communicate the desired
type(s) of exclusion. The following flags are defined. type(s) of exclusion. The following flags are defined. Any
combination of these flags is permitted.
0x01 = SRLG exclusion 0x01 = SRLG exclusion
Indicates that the path of the LSP being signaled is Indicates that the path of the LSP being signaled is
requested to be SRLG diverse from the excluded path requested to be SRLG-diverse from the excluded path
specified by the Diversity subobject. specified by the Diversity XRO subobject.
0x02 = Node exclusion 0x02 = Node exclusion
Indicates that the path of the LSP being signaled is Indicates that the path of the LSP being signaled is
requested to be node diverse from the excluded path requested to be node-diverse from the excluded path
specified by the Diversity subobject. specified by the Diversity XRO subobject.
(Note: the meaning of this flag may be modified by (Note: the meaning of this flag may be modified by
the value of the Attribute-flags.) the value of the Attribute-flags.)
0x04 = Link exclusion 0x04 = Link exclusion
Indicates that the path of the LSP being signaled is Indicates that the path of the LSP being signaled is
requested to be link diverse from the path specified requested to be link-diverse from the path specified
by the Diversity subobject. by the Diversity XRO subobject.
Internet Draft draft-ietf-ccamp-lsp-diversity-04.txt
TLVs (Type-Length-Value tuples) have the following format. Only
one TLV is allowed in the Diversity XRO subobject. However,
multiple Diversity XRO subobjects may be present in an XRO.
0 1 2 3 Resvd
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
// //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Types (2 bytes): This document defines the following types of Internet Draft draft-ietf-ccamp-lsp-diversity-05.txt
TLVs:
- Type = 1: IPv4 Point-to-Point tunnel identifier. This field is reserved. It SHOULD be set to zero on
transmission, and MUST be ignored on receipt.
- Type = 2: IPv6 Point-to-Point tunnel identifier. IPv4 Diversity Identifier source address:
- Type = 3: IPv4 Path Key. This field is set to the IPv4 address of the node that
assigns the diversity identifier. Depending on the
diversity identifier type, the diversity identifier source
may be a client node, PCE entity or network node.
Specifically:
- Type = 4: IPv6 Path Key. o When the diversity identifier type is set to "IPv4 Client
Initiated Identifier", the value is set to IPv4 tunnel
sender address of the reference LSP against which
diversity is desired. IPv4 tunnel sender address is as
defined in [RFC3209].
- Type = 5: IPv4 Path Affinity Set (PAS). o When the diversity identifier type is set to "IPv4 PCE
Allocated Identifier", the value indicates the IPv4
address of the node that assigned the Path Key identifier
and that can return an expansion of the Path Key or use
the Path Key as exclusion in a path computation. The Path
Key is defined in [RFC5553].
- Type = 6: IPv6 Path Affinity Set (PAS). o When the diversity identifier type is set to "IPv4
Network Assigned Identifier", the value indicates the IPv4
address of the node publishing the Path Affinity Set
(PAS).
Format of the individual TLVs is described in the following. Diversity Identifier Value:
2.1.1. Tunnel identifier TLVs Encoding for this field depends on the diversity identifier
type, as defined in the following.
The IPv4 and IPv6 Point-to-Point (P2P) tunnel identifier TLVs for When the diversity identifier type is set to "IPv4 Client
diversity XRO subobjects are defined as follows. Initiated Identifier", the diversity identifier value is
encoded as follows:
2.1.1.1. IPv4 Point-to-Point tunnel identifier TLV Internet Draft draft-ietf-ccamp-lsp-diversity-05.txt
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 | Length = 24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel end point address | | IPv4 tunnel end point address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Internet Draft draft-ietf-ccamp-lsp-diversity-04.txt
| Must Be Zero | Tunnel ID | | Must Be Zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID | | Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel sender address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | LSP ID | | Must Be Zero | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: The IPv4 tunnel end point address, Tunnel ID, Extended
Tunnel ID and LSP ID are as defined in [RFC3209].
IPv4 Point-to-Point tunnel identifier TLV (to be assigned
by IANA; suggested value: 1).
Length:
The length contains the total length of the TLV in bytes,
including the type and length fields. The length is always
24.
The remaining fields are as defined in [RFC3209].
Please note that the L-bit, exclusion and attribute flags
defined at the diversity XRO subobject level in Section 2.1
are equally applicable to the IPv4 Point-to-Point tunnel
identifier TLV.
2.1.1.2. IPv6 Point-to-Point tunnel identifier TLV When the diversity identifier type is set to "IPv4 PCE
Allocated Identifier", the diversity identifier value is
encoded 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 2 | Length = 60 | | Must Be Zero | Path Key |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 tunnel end point address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 tunnel end point address (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 tunnel end point address (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 tunnel end point address (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | Tunnel ID |
Internet Draft draft-ietf-ccamp-lsp-diversity-04.txt The Path Key is defined in [RFC5553].
When the diversity identifier type is set to "IPv4 Network
Assigned Identifier", the diversity identifier value is
encoded as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID | | Path Affinity Set (PAS) identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 tunnel sender address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 tunnel sender address (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 tunnel sender address (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 tunnel sender address (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: The Path affinity Set (PAS) identifier is a single number
that represents a summarized SRLG for the reference path
IPv6 Point-to-Point tunnel identifier TLV (to be assigned against which diversity is desired. The node identified by
by IANA; suggested value: 2). the "IPv4 Diversity Identifier source address" field of
the diversity XRO subobject assigns the PAS value.
Length:
The length contains the total length of the TLV in bytes,
including the type and length fields. The length is always
60.
The remaining fields are as defined in [RFC3209].
Please note that the L-bit, exclusion and attribute flags
defined at the diversity XRO subobject level in Section 2.1
are equally applicable to the IPv6 Point-to-Point tunnel
identifier TLV.
2.1.2. Path Key TLVs
The IPv4 and IPv6 Path Key TLVs for diversity XRO subobjects are
defined as follows.
Internet Draft draft-ietf-ccamp-lsp-diversity-04.txt Internet Draft draft-ietf-ccamp-lsp-diversity-05.txt
2.1.2.1. IPv4 Path Key TLV 2.1.2. IPv6 Diversity XRO 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 3 | Length = 12 | |L| XRO Type | Length |DI Type|A-Flags|E-Flags| Resvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | Path Key |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCE ID (4 bytes) | | IPv6 Diversity Identifier source address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Diversity Identifier source address (cont.) |
Type:
IPv4 Path Key TLV (to be assigned by IANA; suggested
value: 3).
Length:
The length contains the total length of the TLV in bytes,
including the type and length fields. The length is always
12.
Path Key:
Path Key is defined in [RFC5553].
PCE-ID:
The IPv4 address of a node that assigned the Path Key
identifier and that can return an expansion of the Path Key
or use the Path Key as exclusion in a path computation.
Please note that exclusion and attribute flags defined at the
diversity XRO subobject level in Section 2.1 are equally
applicable to the IPv4 Path Key TLV.
2.1.2.2. IPv6 Path Key TLV
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 4 | Length = 24 | | IPv6 Diversity Identifier source address (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Diversity Identifier source address (cont.) |
Internet Draft draft-ietf-ccamp-lsp-diversity-04.txt
| Must Be Zero | Path Key |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCE ID (16 bytes) | | Diversity Identifier Value |
| | // ... //
| |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: L:
The L-flag is used as for the XRO subobjects defined in
IPv4 Path Key TLV (to be assigned by IANA; suggested [RFC4874], i.e.,
value: 4).
Length:
The length contains the total length of the TLV in bytes, 0 indicates that the attribute specified MUST be excluded.
including the type and length fields. The length is always
24.
Path Key: 1 indicates that the attribute specified SHOULD be avoided.
Path Key is defined in [RFC5553]. XRO Type
PCE-ID: Type for IPv6 diversity XRO subobject (to be assigned by
IANA; suggested value: 38).
The IPv6 address of a node that assigned the Path Key Length
identifier and that can return an expansion of the Path Key
or use the Path Key as exclusion in a path computation.
Please note that the L-bit, exclusion and attribute flags The Length contains the total length of the subobject in
defined at the diversity XRO subobject level in Section 2.1 bytes, including the Type and Length fields. The Length is
are equally applicable to the IPv6 Path Key TLV. variable, depending on the diversity identifier value.
2.1.3. Path Affinity Set TLVs Attribute Flags (A-Flags):
The IPv4 and IPv6 Path Affinity Set (PAS) TLVs for diversity XRO As defined in Section 2.1.1 for the IPv4 counterpart.
subobjects are defined as follows.
2.1.3.1. IPv4 PAS TLV Internet Draft draft-ietf-ccamp-lsp-diversity-05.txt
0 1 2 3 Exclusion Flags (E-Flags):
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Internet Draft draft-ietf-ccamp-lsp-diversity-04.txt As defined in Section 2.1.1 for the IPv4 counterpart.
| Type = 5 | Length = 16 | Resvd
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path Affinity Set identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Path Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Path Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: This field is reserved. It SHOULD be set to zero on
transmission, and MUST be ignored on receipt.
IPv4 PAS TLV (to be assigned by IANA; suggested value: 5). Diversity Identifier Type (DI Type)
Length: This field is defined in the same fashion as its IPv4
counter part described in Section 2.1.1.
The DI Types associated with IPv6 addresses are defined,
as follows:
The length contains the total length of the TLV in bytes, IPv6 Client Initiated Identifier 4 (to be assigned by
including the type and length fields. The length is always IANA)
16. IPv6 PCE Allocated Identifier 5 (to be assigned by
IANA)
IPv6 Network Assigned Identifier 6 (to be assigned by
IANA)
Path Affinity Set identifier: These idenifier are assigned and used as defined in
The Path affinity Set identifier (4 bytes) is a single Section 2.1.1.
number that represents a summarized SRLG for this path.
IPv4 Path Source Address: IPv4 Diversity Identifier source address:
The IPv4 address of the source node associated with the This field is set to IPv6 address of the node that assigns
Path. the diversity identifier. How identity of node for various
diversity types is determined is as described in Section
2.1.1 for the IPv4 counterpart.
IPv4 Path Destination Address: Diversity Identifier Value:
The IPv4 address of the destination node associated with Encoding for this field depends on the diversity identifier
the Path. type, as defined in the following.
Please note that L-bit, exclusion and attribute flags defined Internet Draft draft-ietf-ccamp-lsp-diversity-05.txt
at the diversity XRO subobject level in Section 2.1 are
equally applicable to the IPv4 PAS TLV.
2.1.3.2. IPv6 PAS TLV When the diversity identifier type is set to "IPv6 Client
Initiated Identifier", the diversity identifier value is
encoded 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
Internet Draft draft-ietf-ccamp-lsp-diversity-04.txt
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 6 | Length = 40 | | IPv6 tunnel end point address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path Affinity Set identifier | | IPv6 tunnel end point address (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Path Source Address | | IPv6 tunnel end point address (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Path Source Address (cont.) | | IPv6 tunnel end point address (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Path Source Address (cont.) | | Must Be Zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Path Source Address (cont.) | | Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Path Destination Address | | Extended Tunnel ID (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Path Destination Address (cont.) | | Extended Tunnel ID (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Path Destination Address (cont.) | | Extended Tunnel ID (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Path Destination Address (cont.) | | Must Be Zero | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: The IPv6 tunnel end point address, Tunnel ID, IPv6 Extended
Tunnel ID and LSP ID are as defined in [RFC3209].
IPv6 PAS TLV (to be assigned by IANA; suggested value: 6).
Length:
The length contains the total length of the TLV in bytes,
including the type and length fields. The length is always
40.
Path Affinity Set identifier: When the diversity identifier type is set to "IPv6 PCE
The Path affinity Set identifier (4 bytes) is a single Allocated Identifier", the diversity identifier value is
number that represents a summarized SRLG for this path. encoded as follows:
IPv6 Path Source Address: 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | Path Key |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The IPv6 address of the source node associated with the The Path Key is defined in [RFC5553].
Path.
IPv6 Path Destination Address: Internet Draft draft-ietf-ccamp-lsp-diversity-05.txt
Internet Draft draft-ietf-ccamp-lsp-diversity-04.txt When the diversity identifier type is set to "IPv6 Network
Assigned Identifier", the diversity identifier value is
encoded as follows:
The IPv6 address of the destination node associated with 0 1 2 3
the Path. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path Affinity Set (PAS) identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Please note that the L-bit, exclusion and attribute flags The Path affinity Set (PAS) identifier is as defined in
defined at the diversity XRO subobject level in Section 2.1 Section 2.1.1.
are equally applicable to the IPv6 PAS TLV.
2.2. Processing rules for the Diversity XRO subobject 2.2. Processing rules for the Diversity XRO subobject
The procedure defined in [RFC4874] for processing XRO and EXRS is The procedure defined in [RFC4874] for processing XRO and EXRS is
not changed by this document. not changed by this document. If the processing node cannot
recognize the IPv4/ IPv6 Diversity XRO subobject, the node is
If the processing node cannot recognize the Diversity XRO expected to follow the procedure defined in [RFC4874].
subobject or the TLV contained in it, the node follows procedure
defined in [RFC4874].
An XRO object MAY contain multiple Diversity subobjects. However, An XRO object MAY contain multiple Diversity subobjects. E.g., In
all Diversity subobjects are expected to contain the same TLV order to exclude multiple Path Keys, an EN may include multiple
type. If a Path message contains an XRO with Diversity subobjects Diversity XRO subobjects each with a different Path Key.
with TLVs of different types, the processing node SHOULD return a Similarly, in order to exclude multiple PAS identifiers, an EN
may include multiple Diversity XRO subobjects each with a
different PAS identifier. However, all Diversity subobjects in an
XRO SHOULD contain the same Diversity Identifier Type. If a Path
message contains an XRO with Diversity subobjects with multiple
Diversity Identifier Types, the processing node SHOULD return a
PathErr with the error code "Routing Problem" (24) and error sub- PathErr with the error code "Routing Problem" (24) and error sub-
code "XRO Too Complex" (68). If the processing node is the code "XRO Too Complex" (68).
destination for the LSP being signaled, it SHOULD NOT process a
Diversity XRO subobject.
The attribute-flags affect the processing of the Diversity XRO The attribute-flags affect the processing of the Diversity XRO
subobject as follows: subobject as follows:
o When the "destination node exception" flag is not set, the o When the "destination node exception" flag is set, the
exclusion flags SHOULD also be respected for the exclusion SHOULD be ignored for the destination node.
destination node.
o When the "processing node exception" flag is not set, the o When the "processing node exception" flag is set, the
exclusion flags SHOULD also be respected for the exclusion SHOULD be ignored for the processing node. The
processing node. processing node is the node performing path calculation.
o When the "penultimate node exception" flag is not set, the Internet Draft draft-ietf-ccamp-lsp-diversity-05.txt
exclusion flags SHOULD also be respected for the
penultimate node.
o The use of "LSP ID to be ignored" flag is only defined for o When the "penultimate node exception" flag is set, the
the IPv4 and IPv6 tunnel identifier TLVs. This flag is exclusion SHOULD be ignored for the penultimate node on
never set and is always ignored in processing all other the path of the LSP being established.
TLVs. When the "LSP ID to be ignored" flag is set, the
processing node MUST calculate a path based on exclusions
Internet Draft draft-ietf-ccamp-lsp-diversity-04.txt o The "LSP ID to be ignored" flag is only defined for the
"IPv4/ IPv6 Client Initiated Identifier" diversity types.
When the Diversity Identifier Type is set to any other
value, this flag SHOULD NOT be set on transmission and
MUST be ignored in processing. When this flag is not set,
the lsp-id is not ignored and the exclusion applies only
to the specified LSP (i.e., LSP level exclusion).
from the paths of all known LSPs matching the tunnel-id, If the L-flag of the diversity XRO subobject is not set, the
source, destination and extended tunnel-id specified in processing node proceeds as follows.
the subobject (i.e., tunnel level exclusion). When this
flag is not set, the lsp-id is not ignored and the
exclusion applies only to the specified LSP (i.e., LSP
level exclusion).
The rest of the processing role depends on the TLV carried by the - "IPv4/ IPv6 Client Initiated Identifiers" Diversity Type: the
object. processing node MUST ensure that any path calculated for the
signaled LSP is diverse from the RSVP TE FEC identified by the
client in the XRO subobject.
2.2.1. Processing rules for the tunnel identifier TLVs - "IPv4/ IPv6 PCE Allocated Identifiers" Diversity Type: the
processing node MUST ensure that any path calculated for the
signaled LSP is diverse from the route identified by the Path-
Key. The processing node MAY use the PCE identified by the IPv4
Diversity Identifier source address in the subobject for route
computation. The processing node MAY use the Path-Key
resolution mechanisms described in [RFC5553].
This section describes processing rules for the IPv4 and IPv6 - "IPv4/ IPv6 Network Assigned Identifiers" Diversity Type: the
tunnel identifier TLVs. processing node MUST ensure that the path calculated for the
signaled LSP respects the requested PAS exclusion. .
If the L-flag of the diversity XRO subobject is not set, the - Regardless of whether the path computation is performed
processing node follows the following procedure: locally or at a remote node (e.g., PCE), the processing node
MUST ensure that any path calculated for the signaled LSP
respects the requested exclusion flags with respect to the
excluded path referenced by the subobject, including local
resources.
- The processing node MUST ensure that any path calculated for - If the excluded path referenced in the XRO subobject is
the signaled LSP respects the requested exclusion flags with unknown to the processing node, the processing node SHOULD
respect to the excluded path referenced by the subobject, ignore the diversity XRO subobject and SHOULD proceed with the
including local resources. signaling request. After sending the Resv for the signaled LSP,
the processing node SHOULD return a PathErr with the error code
"Notify Error" (25) and error sub-code "Route reference in
diversity XRO identifier unknown" (value to be assigned by
IANA, suggested value: 13) for the signaled LSP.
Internet Draft draft-ietf-ccamp-lsp-diversity-05.txt
- If the processing node fails to find a path that meets the - If the processing node fails to find a path that meets the
requested constraint, the processing node MUST return a PathErr requested constraint, the processing node MUST return a PathErr
with the error code "Routing Problem" (24) and error sub-code with the error code "Routing Problem" (24) and error sub-code
"Route blocked by Exclude Route" (67). "Route blocked by Exclude Route" (67).
- If the excluded path referenced in the tunnel identifier TLV
is unknown to the processing node, the processing node SHOULD
ignore the tunnel identifier TLV in the diversity XRO subobject
of XRO and SHOULD proceed with the signaling request. After
sending the Resv for the signaled LSP, the processing node
SHOULD return a PathErr with the error code "Notify Error" (25)
and error sub-code "Route of XRO tunnel identifier unknown"
(value to be assigned by IANA, suggested value: 13) for the
signaled LSP.
If the L-flag of the diversity XRO subobject is set, the If the L-flag of the diversity XRO subobject is set, the
processing node follows the procedure below: processing node proceeds as follows:
- "IPv4/ IPv6 Client Initiated Identifiers" Diversity Type: the
processing node SHOULD ensure that the path calculated for the
signaled LSP is diverse from the RSVP TE FEC identified by the
client in the XRO subobject.
- "IPv4/ IPv6 PCE Allocated Identifiers" Diversity Type: the
processing node SHOULD ensure that the path calculated for the
signaled LSP is diverse from the route identified by the Path-
Key.
"IPv4/ IPv6 Network Assigned Identifiers" Diversity Type: the
processing node SHOULD ensure that the path calculated for the
signaled LSP respects the requested PAS exclusion. The means by
which the processing node determines the path corresponding to
the PAS is beyond the scope of this document.
- The processing node SHOULD respect the requested exclusion - The processing node SHOULD respect the requested exclusion
flags with respect to the excluded path to the extent possible. flags with respect to the excluded path to the extent possible.
- If the processing node fails to find a path that meets the - If the processing node fails to find a path that meets the
requested constraint, it SHOULD proceed with signaling using a requested constraint, it SHOULD proceed with signaling using a
suitable path that meets the constraint as far as possible. suitable path that meets the constraint as far as possible.
Internet Draft draft-ietf-ccamp-lsp-diversity-04.txt
After sending the Resv for the signaled LSP, it SHOULD return a After sending the Resv for the signaled LSP, it SHOULD return a
PathErr message with error code "Notify Error" (25) and error PathErr message with error code "Notify Error" (25) and error
sub-code "Failed to respect Exclude Route" (value: to be sub-code "Failed to respect Exclude Route" (value: to be
assigned by IANA, suggest value: 14) to the source node. assigned by IANA, suggest value: 14) to the source node.
- If the excluded path referenced in the tunnel identifier TLV
is unknown to the processing node, the processing node SHOULD
ignore the tunnel identifier TLV in the diversity XRO subobject
of XRO and SHOULD proceed with the signaling request. After
sending the Resv for signaled LSP, the processing node SHOULD
return a PathErr message with the error code "Notify Error"
(25) and error sub-code "Route of XRO tunnel identifier
unknown" for the signaled LSP.
If, subsequent to the initial signaling of a diverse LSP: If, subsequent to the initial signaling of a diverse LSP:
- An excluded path referenced in the diverse LSP's XRO tunnel - An excluded path referenced in the XRO subobject becomes
identifier becomes known to the processing node (e.g. when the known to the processing node, or a change in the excluded path
excluded path is signaled), or becomes known to the processing node, the processing node
SHOULD re-evaluate the exclusion and diversity constraints
- A change in the excluded path becomes known to the processing requested by the diverse LSP to determine whether they are
node, the processing node SHOULD re-evaluate the exclusion and still satisfied.
diversity constraints requested by the diverse LSP to determine
whether they are still satisfied.
- If the requested exclusion constraints for the diverse LSP - If the requested exclusion constraints for the diverse LSP are
are no longer satisfied and an alternative path for the diverse no longer satisfied and an alternative path for the diverse LSP
LSP that can satisfy those constraints exists, the processing that can satisfy those constraints exists, then:
node SHOULD send a PathErr message for the diverse LSP with the
error code "Notify Error" (25) and a new error sub-code
"compliant path exists" (value: to be assigned by IANA, suggest
value: 15). A source node receiving a PathErr message with this
error code and sub-code combination MAY try to reoptimize the
diverse tunnel to the new compliant path.
- If the requested exclusion constraints for the diverse LSP Internet Draft draft-ietf-ccamp-lsp-diversity-05.txt
are no longer satisfied and no alternative path for the diverse
LSP that can satisfy those constraints exists, then:
o If the L-flag was not set in the original exclusion, the o If the L-flag was not set in the original exclusion, the
processing node MUST send a PathErr message for the processing node MUST send a PathErr message for the
diverse LSP with the error code "Routing Problem" (24) and diverse LSP with the error code "Routing Problem" (24) and
error sub-code "Route blocked by Exclude Route" (67). The error sub-code "Route blocked by Exclude Route" (67). The
PSR flag SHOULD NOT be set. PSR flag SHOULD NOT be set. A source node receiving a
PathErr message with this error code and sub-code
combination SHOULD take appropriate actions to migrate the
compliant path.
o If the L-flag was set in the original exclusion, the o If the L-flag was set in the original exclusion, the
processing node SHOULD send a PathErr message for the processing node SHOULD send a PathErr message for the
diverse LSP with the error code "Notify Error" (25) and a
new error sub-code "compliant path exists" (value: to be
assigned by IANA, suggest value: 15). The PSR flag SHOULD
NOT be set. A source node receiving a PathErr message with
this error code and sub-code combination MAY signal a new
LSP to migrate the compliant path.
Internet Draft draft-ietf-ccamp-lsp-diversity-04.txt - If the requested exclusion constraints for the diverse LSP are
no longer satisfied and no alternative path for the diverse LSP
that can satisfy those constraints exists, then:
o If the L-flag was not set in the original exclusion, the
processing node MUST send a PathErr message for the
diverse LSP with the error code "Routing Problem" (24) and
error sub-code "Route blocked by Exclude Route" (67). The
PSR flag SHOULD be set.
o If the L-flag was set in the original exclusion, the
processing node SHOULD send a PathErr message for the
diverse LSP with the error code error code "Notify Error" diverse LSP with the error code error code "Notify Error"
(25) and error sub-code "Failed to respect Exclude Route" (25) and error sub-code "Failed to respect Exclude Route"
(value: to be assigned by IANA, suggest value: 14). (value: to be assigned by IANA, suggest value: 14). The
PSR flag SHOULD NOT be set.
The following rules apply whether or not the L-flag is set: The following rules apply whether or not the L-flag is set:
- A source node receiving a PathErr message with the error code - A source node receiving a PathErr message with the error code
"Notify Error" (25) and error sub-codes "Route of XRO tunnel "Notify Error" (25) and error sub-codes "Route of XRO tunnel
identifier unknown" or "Failed to respect Exclude Route" MAY identifier unknown" or "Failed to respect Exclude Route" MAY
take no action. take no action.
2.2.2. Processing rules for the Path Key TLVs
This section describes processing rules for the IPv4 and IPv6
Path Key TLVs.
An EN may include a path-key identifier (PKS) in the path-key
TLVs of the diversity XRO subobject to convey diversity
constraints. In order to exclude multiple PKS, an EN may include
multiple diversity XRO subobjects each with a different path-key.
If the node, receiving the path-key TLV, cannot recognize the
subobject, it will react according to [RFC4874] and SHOULD ignore
the constraint. Otherwise, if it decodes the path-key TLV but
cannot find a route/route segment meeting the constraint:
-if L flag is set to 0, it will react according to [RFC4874]
and SHOULD send a PathErr message with the error code
"Routing Problem" (24) and the error sub-code "Route blocked
by Exclude Route" (67).
-if L flag is set to 1, which means the node SHOULD try to
be as much diversified as possible with the specified
resource. If it cannot fully support the constraint, it
SHOULD send a PathErr message with the error code/value
combination "Notify Error" / "Failed to respect Exclude
Route" (value: to be assigned by IANA, suggest value: 14).
The following rules apply whether or not the L-flag is set:
- A source node receiving a PathErr message with the error code
"Notify Error" (25) and error sub-codes "Failed to respect
Exclude Route" MAY take no action.
This mechanism can work with all the PKS resolution mechanisms,
as detailed in [RFC5553] section 3.1. A PCE, co-located or not,
may be used to resolve the PKS, but the node (i.e., a Label
Internet Draft draft-ietf-ccamp-lsp-diversity-04.txt
Switcher Router (LSR)) can also use the PKS information to index
a Path Segment previously supplied to it by the entity that
originated the PKS, for example the LSR that inserted the PKS in
the RRO or a management system.
2.2.3. Processing rules for the PAS TLVs
This section describes processing rules for the IPv4 and IPv6 PAS
TLVs.
An EN may include a PAS identifier in the PAS TLVs of the
diversity XRO subobject to convey diversity constraints. In order
to exclude multiple PAS identifiers, an EN may include multiple
diversity XRO subobjects each with a different PAS identifier.
How an EN determines the PAS identifier is a local matter for the
EN administrator. This identifier is a suggested identifier and
may be overridden by a CN under some conditions, regardless if L
bit is set or not. For example, a PAS identifier can be used with
no prior exchange of PAS information between the EN and the CN.
Upon reception of the PAS identifier information the CN can infer
the EN's requirements. The actual PAS identifier used will be
returned in the RESV message.
If the L-flag of the diversity XRO subobject is not set, the
processing node follows the following procedure:
- The processing node MUST ensure that any path calculated for
the signaled LSP respects the requested PAS exclusion,
including local resources.
- If the processing node fails to find a path that meets the
requested constraint, the processing node MUST return a PathErr
with the error code "Routing Problem" (24) and error sub-code
"Route blocked by Exclude Route" (67).
- If the PAS value referenced in the PAS TLV is unknown to the
processing node, the processing node MAY infer the diversity
requirement. After sending the Resv for the signaled LSP, the
processing node SHOULD return a PathErr with the error code
"Notify Error" (25) and error sub-code "XRO PAS value inferred"
(value to be assigned by IANA, suggested value: TBD). However,
if processing node fails to infer the diversity requirement
from PAS value, it MUST return a PathErr with the error code
"Routing Problem" (24) and error sub-code "Route blocked by
Exclude Route" (67).
Internet Draft draft-ietf-ccamp-lsp-diversity-04.txt
If the L-flag of the diversity XRO subobject is set, the
processing node follows the procedure below:
- The processing node SHOULD ensure that any path calculated for
the signaled LSP respects the requested PAS exclusion,
including local resources.
- If the processing node fails to find a path that meets the
requested constraint, it SHOULD proceed with signaling using a
suitable path that meets the constraint as far as possible.
After sending the Resv for the signaled LSP, it SHOULD return a
PathErr message with error code "Notify Error" (25) and error
sub-code "Failed to respect Exclude Route" (value: to be
assigned by IANA, suggest value: 14) to the source node.
- If the PAS value referenced in the PAS TLV is unknown to the
processing node, the processing node MAY infer the diversity
requirement. However, if processing node fails to infer the
diversity requirement it MAY ignore the PAS TLV in the
diversity XRO subobject of XRO and SHOULD proceed with the
signaling request. After sending the Resv for signaled LSP, the
processing node SHOULD return a PathErr message with the error
code "Notify Error" (25) and error sub-code "Failed to respect
Exclude Route" (value: to be assigned by IANA, suggest value:
14) to the source node.
In the context of VPN, upon reception of the PAS identifier
information, the CN looks up the CN based addresses in the
Provider Index Table (PIT). The CN also looks up the SRLG
information (or equivalent) in the core network that is
associated with LSPs belonging to the same Path Affinity Set and
exclude those resources from the path computation for this LSP.
The CN may alternatively choose from an existing path with a
disjoint set of resources.
Optionally the EN may use a value of all zeros in the PAS
identifier allowing the CN to select an appropriate PAS
identifier. Also the CN may to override the PAS identifier
allowing the CN to re-assign the identifier if required. An EN
should not assume that the PAS identifier used for setup is the
actual PAS identifier.
Internet Draft draft-ietf-ccamp-lsp-diversity-04.txt
2.2.3.1.1. Distribution of the Path Affinity Set Information
Information about TE link SRLGs is already available in the IGP
TE database. A core network can be designed to have additional
opaque records for core network paths that distribute EN paths,
PAS values associated with them and SRLG on a VPN basis. When a
core network path is setup, the following information allows a CN
to lookup the CN diversity information:
. L1 VPN Identifier
. Path Affinity Set Identifier
. Source CN Address
. Destination CN Address
. List of core network SRLGs (variable)
The source CN address and destination CN address are the same
addresses in the VPN PIT and correspond to the respective EN
address identifiers.
Note that all of the information is local to the CN context and
is not shared with the EN. The VPN Identifier is associated with
an EN. The only value that is signaled from the EN is the Path
Affinity Set and optionally the addresses of an existing LSP. The
CN stores source and destination CN addresses of the LSP in their
native format along with the SRLG information. This information
is internal to the core network and is assumed to be known.
2.3. Diversity EXRS Subobject 2.3. Diversity EXRS Subobject
[RFC4874] defines the EXRS ERO subobject. An EXRS is used to [RFC4874] defines the EXRS ERO subobject. An EXRS is used to
identify abstract nodes or resources that must not or should not identify abstract nodes or resources that must not or should not
be used on the path between two inclusive abstract nodes or be used on the path between two inclusive abstract nodes or
Internet Draft draft-ietf-ccamp-lsp-diversity-05.txt
resources in the explicit route. An EXRS contains one or more resources in the explicit route. An EXRS contains one or more
subobjects of its own, called EXRS subobjects [RFC4874]. subobjects of its own, called EXRS subobjects [RFC4874].
An EXRS MAY include Diversity subobject as specified in this An EXRS MAY include Diversity subobject as specified in this
document. In this case, the EXRS format would be as follows: document. In this case, the IPv4 EXRS format is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | Reserved | |L| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| XRO Type | Length |DI Type|A-Flags|E-Flags| Resvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Diversity Identifier source address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Diversity Identifier Value |
// ... //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Internet Draft draft-ietf-ccamp-lsp-diversity-04.txt Similarly, the IPv6 EXRS format is as follows:
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 |Attribute Flags|Exclusion Flags| Reserved | |L| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLVs ... | |L| XRO Type | Length |DI Type|A-Flags|E-Flags| Resvd |
// // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Diversity Identifier source address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Diversity Identifier source address (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Diversity Identifier source address (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Diversity Identifier source address (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Diversity Identifier Value |
// ... //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Internet Draft draft-ietf-ccamp-lsp-diversity-05.txt
The meanings of respective fields in EXRS header are as defined The meanings of respective fields in EXRS header are as defined
in [RFC4874]. The meanings of respective fields in Diversity in [RFC4874]. The meanings of respective fields in the Diversity
subobject are as defined earlier in this document. subobject are as defined earlier in this document for the XRO
subobject.
The processing rules for the EXRS object are unchanged from The processing rules for the EXRS object are unchanged from
[RFC4874]. When the EXRS contains one or more Diversity [RFC4874]. When the EXRS contains one or more Diversity
subobject(s), the processing rules specified in Section 2.3 apply subobject(s), the processing rules specified in Section 2.2 apply
to the node processing the ERO with the EXRS subobject. to the node processing the ERO with the EXRS subobject.
If a loose-hop expansion results in the creation of another If a loose-hop expansion results in the creation of another
loose-hop in the outgoing ERO, the processing node MAY include loose-hop in the outgoing ERO, the processing node MAY include
the EXRS in the newly created loose hop for further processing by the EXRS in the newly created loose hop for further processing by
downstream nodes. downstream nodes.
The processing node exception for the EXRS subobject applies to The processing node exception for the EXRS subobject applies to
the node processing the ERO. the node processing the ERO.
skipping to change at page 27, line 5 skipping to change at page 22, line 43
that identifies the next abstract node. This flag is only that identifies the next abstract node. This flag is only
processed if the L bit is set in the ERO subobject that processed if the L bit is set in the ERO subobject that
identifies the next abstract node. identifies the next abstract node.
3. Security Considerations 3. Security Considerations
This document does not introduce any additional security issues This document does not introduce any additional security issues
above those identified in [RFC5920], [RFC2205], [RFC3209], above those identified in [RFC5920], [RFC2205], [RFC3209],
[RFC3473] and [RFC4874]. [RFC3473] and [RFC4874].
Internet Draft draft-ietf-ccamp-lsp-diversity-04.txt
4. IANA Considerations 4. IANA Considerations
4.1. New XRO subobject types 4.1. New XRO subobject types
IANA registry: RSVP PARAMETERS IANA registry: RSVP PARAMETERS
Subsection: Class Names, Class Numbers, and Class Types Subsection: Class Names, Class Numbers, and Class Types
This document introduces two new subobjects for the EXCLUDE_ROUTE This document introduces two new subobjects for the EXCLUDE_ROUTE
object [RFC4874], C-Type 1. object [RFC4874], C-Type 1.
Internet Draft draft-ietf-ccamp-lsp-diversity-05.txt
Subobject Description Subobject Type Subobject Description Subobject Type
-------------- --------------------- -------------- ---------------------
Diversity subobject To be assigned by IANA IPv4 Diversity subobject To be assigned by IANA
(suggested value: 36) (suggested value: 37)
IPv6 Diversity subobject To be assigned by IANA
(suggested value: 38)
4.2. New EXRS subobject types 4.2. New EXRS subobject types
The diversity XRO subobjects are also defined as new EXRS The diversity XRO subobjects are also defined as new EXRS
subobjects. subobjects.
4.3. TLV types for Diversity XRO and EXRS subobjects 4.3. New RSVP error sub-codes
The following TLV types for Diversity XRO and EXRS subobjects are
defined.
TLV Description TLV Type
--------------- --------
IPv4 Point-to-Point tunnel identifier To be assigned by IANA
(suggested value: 1)
IPv6 Point-to-Point tunnel identifier To be assigned by IANA
(suggested value: 2)
IPv4 Path Key To be assigned by IANA
(suggested value: 3)
IPv6 Path Key To be assigned by IANA
(suggested value: 4)
IPv4 Path Affinity Set To be assigned by IANA
(suggested value: 5)
IPv6 Path Affinity Set To be assigned by IANA
(suggested value: 6)
Internet Draft draft-ietf-ccamp-lsp-diversity-04.txt
4.4. New RSVP error sub-codes
IANA registry: RSVP PARAMETERS IANA registry: RSVP PARAMETERS
Subsection: Error Codes and Globally Defined Error Value Sub- Subsection: Error Codes and Globally Defined Error Value Sub-
Codes Codes
For Error Code "Notify Error" (25) (see [RFC3209]) the following For Error Code "Notify Error" (25) (see [RFC3209]) the following
sub-codes are defined. sub-codes are defined.
Sub-code Value Sub-code Value
-------- ----- -------- -----
Route of XRO To be assigned by IANA. Route of XRO To be assigned by IANA.
tunnel identifier unknown Suggested Value: 13. tunnel identifier unknown Suggested Value: 13.
Failed to respect Exclude Route To be assigned by IANA. Failed to respect Exclude Route To be assigned by IANA.
Suggested Value: 14. Suggested Value: 14.
Compliant path exists To be assigned by IANA. Compliant path exists To be assigned by IANA.
Suggested Value: 15. Suggested Value: 15.
XRO PAS value inferred To be assigned by IANA.
Suggested Value: 16
5. Acknowledgements 5. Acknowledgements
The authors would like to thank Luyuan Fang and Walid Wakim for The authors would like to thank Luyuan Fang and Walid Wakim for
their review comments. their review comments.
Internet Draft draft-ietf-ccamp-lsp-diversity-05.txt
6. References 6. References
6.1. Normative References 6.1. Normative References
[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, [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
V., and G. Swallow, "RSVP-TE: Extensions to RSVP for V., and G. Swallow, "RSVP-TE: Extensions to RSVP for
LSP Tunnels", RFC 3209, December 2001. LSP 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 Engineering (RSVP-TE) Extensions", RFC 3473, January
2003. 2003.
Internet Draft draft-ietf-ccamp-lsp-diversity-04.txt
[RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude [RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude
Routes - Extension to Resource ReserVation Protocol- Routes - Extension to Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE)", RFC 4874, April 2007. Traffic Engineering (RSVP-TE)", RFC 4874, April 2007.
[RFC5553] Farrel, A., Ed., Bradford, R., and JP. Vasseur, [RFC5553] Farrel, A., Ed., Bradford, R., and JP. Vasseur,
"Resource Reservation Protocol (RSVP) Extensions for Path Key "Resource Reservation Protocol (RSVP) Extensions for Path Key
Support", RFC 5553, May 2009. Support", RFC 5553, May 2009.
6.2. Informative References 6.2. Informative References
skipping to change at page 29, line 37 skipping to change at page 25, line 5
[RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel, [RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel,
"Preserving Topology Confidentiality in Inter-Domain "Preserving Topology Confidentiality in Inter-Domain
Path Computation Using a Path-Key-Based Mechanism", RFC Path Computation Using a Path-Key-Based Mechanism", RFC
5520, April 2009. 5520, April 2009.
[DRAFT-SRLG-RECORDING] F. Zhang, D. Li, O. Gonzalez de Dios, C. [DRAFT-SRLG-RECORDING] F. Zhang, D. Li, O. Gonzalez de Dios, C.
Margaria, "RSVP-TE Extensions for Collecting SRLG Margaria, "RSVP-TE Extensions for Collecting SRLG
Information", draft-ietf-ccamp-rsvp-te-srlg-collect.txt, Information", draft-ietf-ccamp-rsvp-te-srlg-collect.txt,
work in progress. work in progress.
Internet Draft draft-ietf-ccamp-lsp-diversity-05.txt
[RFC2205] Braden, R. (Ed.), Zhang, L., Berson, S., Herzog, S. and [RFC2205] Braden, R. (Ed.), Zhang, L., Berson, S., Herzog, S. and
S. Jamin, "Resource ReserVation Protocol -- Version 1 S. Jamin, "Resource ReserVation Protocol -- Version 1
Functional Specification", RFC 2205, September 1997. Functional Specification", RFC 2205, September 1997.
[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned
Virtual Private Network (VPN) Terminology", RFC 4026, Virtual Private Network (VPN) Terminology", RFC 4026,
March 2005. March 2005.
[RFC5253] Takeda, T., Ed., "Applicability Statement for Layer 1 [RFC5253] Takeda, T., Ed., "Applicability Statement for Layer 1
Virtual Private Network (L1VPN) Basic Mode", RFC 5253, Virtual Private Network (L1VPN) Basic Mode", RFC 5253,
July 2008. July 2008.
Internet Draft draft-ietf-ccamp-lsp-diversity-04.txt
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010. Networks", RFC 5920, July 2010.
Contributor's Addresses Contributors' Addresses
Igor Bryskin Igor Bryskin
ADVA Optical Networking ADVA Optical Networking
Email: ibryskin@advaoptical.com Email: ibryskin@advaoptical.com
Daniele Ceccarelli Daniele Ceccarelli
Ericsson Ericsson
Email: Daniele.Ceccarelli@ericsson.com Email: Daniele.Ceccarelli@ericsson.com
Dhruv Dhody Dhruv Dhody
skipping to change at page 30, line 38 skipping to change at page 26, line 4
Don Fedyk Don Fedyk
Hewlett-Packard Hewlett-Packard
Email: don.fedyk@hp.com Email: don.fedyk@hp.com
Clarence Filsfils Clarence Filsfils
Cisco Systems, Inc. Cisco Systems, Inc.
Email: cfilsfil@cisco.com Email: cfilsfil@cisco.com
Xihua Fu Xihua Fu
ZTE ZTE
Email: fu.xihua@zte.com.cn
Internet Draft draft-ietf-ccamp-lsp-diversity-04.txt Internet Draft draft-ietf-ccamp-lsp-diversity-05.txt
Email: fu.xihua@zte.com.cn
Gabriele Maria Galimberti Gabriele Maria Galimberti
Cisco Systems Cisco Systems
Email: ggalimbe@cisco.com Email: ggalimbe@cisco.com
Ori Gerstel Ori Gerstel
SDN Solutions Ltd. SDN Solutions Ltd.
Email: origerstel@gmail.com Email: origerstel@gmail.com
Matt Hartley Matt Hartley
skipping to change at page 32, line 4 skipping to change at page 27, line 4
Yuji Tochio Yuji Tochio
Fujitsu Fujitsu
Email: tochio@jp.fujitsu.com Email: tochio@jp.fujitsu.com
Xian Zhang Xian Zhang
Huawei Technologies Huawei Technologies
Email: zhang.xian@huawei.com Email: zhang.xian@huawei.com
Authors' Addresses Authors' Addresses
Internet Draft draft-ietf-ccamp-lsp-diversity-04.txt Internet Draft draft-ietf-ccamp-lsp-diversity-05.txt
Zafar Ali Zafar Ali
Cisco Systems. Cisco Systems.
Email: zali@cisco.com Email: zali@cisco.com
Dieter Beller Dieter Beller
Alcatel-Lucent Alcatel-Lucent
Email: Dieter.Beller@alcatel-lucent.com Email: Dieter.Beller@alcatel-lucent.com
George Swallow George Swallow
 End of changes. 192 change blocks. 
800 lines changed or deleted 558 lines changed or added

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