draft-ietf-teas-lsp-diversity-05.txt   draft-ietf-teas-lsp-diversity-06.txt 
TEAS Working Group Zafar Ali, Ed. TEAS 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: December 23, 2016 F. Zhang, Ed. Updates RFC4874 F. Zhang, Ed.
Huawei Expires: April 21, 2017 Huawei
D. Beller, Ed. D. Beller, Ed.
Nokia Nokia
June 24, 2016 October 18, 2016
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-teas-lsp-diversity-05.txt draft-ietf-teas-lsp-diversity-06.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 December 23, 2016. This Internet-Draft will expire on April 21, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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 This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License. warranty as described in the Simplified BSD License.
Abstract Abstract
RFC 4874 specifies methods by which path exclusions can be Resource ReserVation Protocol-Traffic Engineering provides support
communicated during RSVP-TE signaling in networks where precise for the communication of exclusion information during labeled switch
explicit paths are not computed by the LSP source node. This path setup. This document specifies three new route exclusion types.
document specifies procedures for additional route exclusion The new types include exclusions based on LSP, PCE, and network
subobject based on Paths currently existing or expected to exist assigned identifiers.
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 Identifier..............................6 1.2. PCE-allocated Identifier.................................6
1.3. Network-Assigned Identifier...........................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.2. Diversity EXRS Subobject.............................15 2.2. Diversity EXRS Subobject................................15
2.3. Processing rules for the Diversity XRO and EXRS 2.3. Processing rules for the Diversity XRO and EXRS
subobjects...........................................16 subobjects..............................................16
3. Security Considerations......................................20 3. Security Considerations......................................20
4. IANA Considerations..........................................21 4. IANA Considerations..........................................20
4.1. New XRO subobject types..............................21 4.1. New XRO subobject types.................................20
4.2. New EXRS subobject types.............................21 4.2. New EXRS subobject types................................21
4.3. New RSVP error sub-codes.............................21 4.3. New RSVP error sub-codes................................21
5. Acknowledgements.............................................22 5. Acknowledgements.............................................22
6. References...................................................22 6. References...................................................22
6.1. Normative References.................................22 6.1. Normative References....................................22
6.2. Informative References...............................23 6.2. Informative References..................................23
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) can be established without sharing network Switched Paths (LSPs) can be established without sharing network
resources, thus greatly reducing the probability of simultaneous resources, thus greatly reducing the probability of simultaneous
connection failures. connection failures.
The source node can compute diverse paths for LSPs when it has The source node can compute diverse paths for LSPs when it has
skipping to change at page 5, line 45 skipping to change at page 5, line 48
- Both client and server understand the identifier. - Both client and server understand the identifier.
- It is necessary to be able to reference the identifier even if - It is necessary to be able to reference the identifier even if
the LSP referenced by it is not yet signaled. the LSP referenced by it is not yet signaled.
- The identifier is to be stable for a long period of time. - The identifier is to be stable for a long period of time.
- The identifier is to be stable even when the referenced LSP is - The identifier is to be stable even when the referenced LSP is
rerouted. rerouted.
- The identifier is to be human-readable.
These requirements are met by using the LSP identifier. The LSP These requirements are met by using the LSP identifier. The LSP
identifier uniquely identifies an LSP in the network and identifier uniquely identifies an LSP in the network and
comprises of the following fields: IPv4/IPv6 tunnel sender comprises of the following fields: IPv4/IPv6 tunnel sender
address, IPv4/IPv6 tunnel end point address, Tunnel ID, LSP ID, address, IPv4/IPv6 tunnel end point address, Tunnel ID, LSP ID,
and Extended Tunnel ID. These fields are defined in [RFC3209], and Extended Tunnel ID. These fields are defined in [RFC3209],
sections 4.6.1.1 and 4.6.2.1. sections 4.6.1.1 and 4.6.2.1.
The usage of the client-initiated identifier is illustrated by The usage of the client-initiated identifier is illustrated by
Figure 1. Suppose a LSP from EN2 to EN4 needs to be diverse with Figure 1. Suppose a LSP from EN2 to EN4 needs to be diverse with
respect to a LSP from EN1 to EN3. The LSP identifier of the EN1- respect to a LSP from EN1 to EN3. The LSP identifier of the EN1-
skipping to change at page 7, line 24 skipping to change at page 7, line 24
| \ --- --- | | --- / --- / --- / | | \ --- --- | | --- / --- / --- / |
| | C |--| D |--+--+--| X |---| Y |--| Z | | | | C |--| D |--+--+--| X |---| Y |--| Z | |
| --- --- | | --- --- --- | | --- --- | | --- --- --- |
| | | | | | | |
--------------------- ----------------------------- --------------------- -----------------------------
Figure 2: A Simple Multi-Domain Network Figure 2: 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. 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.
skipping to change at page 8, line 18 skipping to change at page 8, line 18
insert the SRLG identifiers associated with LSP1 as diversity insert the SRLG identifiers associated with LSP1 as diversity
constraints into the XRO using the procedure described in constraints into the XRO using the procedure described in
[RFC4874]. However, if the core network SRLG identifiers are [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, existing mechanisms cannot be policies enforced by core network, existing mechanisms cannot be
used. used.
In this draft, a signaling mechanism is defined where information In this draft, a signaling mechanism is defined where information
signaled to the CN via the UNI does not require shared knowledge signaled to the CN via the UNI does not require shared knowledge
of core network SRLG information. For this purpose, the concept of core network SRLG information. For this purpose, the concept
of a Path Affinity Set (PAS) is used for abstracting SRLG of a Path Affinity Set (PAS) is defined for abstracting SRLG
information. The motive behind the introduction of the PAS is to information. The motive behind the introduction of the PAS is to
minimize the exchange of diversity information between the core minimize the exchange of diversity information between the core
network (CNs) and the client devices (ENs). The PAS contains an network (CNs) and the client devices (ENs). The PAS contains an
abstract SRLG identifier associated with a given path rather than abstract SRLG identifier associated with a given path rather than
a detailed SRLG list. The PAS is a single identifier that can be a detailed SRLG list. The PAS is a single identifier that can be
used to request diversity and associate diversity. The means by used to request diversity and associate diversity. The means by
which the processing node determines the path corresponding to which the processing node determines the path corresponding to
the PAS is beyond the scope of this document. 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
skipping to change at page 8, line 45 skipping to change at page 8, line 45
computation. If a PAS identifier is included for exclusion in the computation. If a PAS identifier is included for exclusion in the
connection request, the CN (UNI-N) in the core network is assumed connection request, the CN (UNI-N) in the core network is assumed
to be able to determine the existing core network SRLG to be able to determine the existing core network SRLG
information and calculate a path that meets the determined information and calculate a path that meets the determined
diversity constraints. diversity constraints.
When a CN satisfies a connection setup for a (SRLG) diverse When a CN satisfies a connection setup for a (SRLG) diverse
signaled path, the CN may optionally record the core network SRLG signaled path, the CN may optionally record the core network SRLG
information for that connection in terms of CN based parameters information for that connection in terms of CN based parameters
and associates that with the EN addresses in the Path message. and associates that with the EN addresses in the Path message.
Specifically for Layer-1 Virtual Private Networks (L1VPNs), Port Specifically, for Layer-1 Virtual Private Networks (L1VPNs), Port
Information Tables (PIT) [RFC5251] can be leveraged to translate Information Tables (PIT) [RFC5251] can be leveraged to translate
between client (EN) addresses and core network addresses. between client (EN) addresses and core network addresses.
The means to distribute the PAS information within the core The means to distribute the PAS information within the core
network is beyond the scope of this document. The PAS and the network is beyond the scope of this document. For example, the
associated SRLG information can be distributed within the core PAS and the associated SRLG information can be distributed within
network by an Interior Gateway Protocol (IGP) or by other means the core network by an Interior Gateway Protocol (IGP) or by
such as configuration. Regardless of means used to distribute the other means such as configuration. Regardless of means used to
PAS information, the information is kept inside core network and distribute the PAS information, the information is kept inside
is not shared with the overlay network (see Figure 1). core network and is not shared with the overlay network (see
Figure 1).
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 below for the IPv4 and New Diversity XRO subobjects are defined below for the IPv4 and
IPv6 address families. Most of the fields in the IPv4 and IPv6 IPv6 address families. Most of the fields in the IPv4 and IPv6
Diversity XRO subobjects are common and are described following Diversity XRO subobjects are common and are described following
the definition of the two subobjects. the definition of the two subobjects.
IPv4 Diversity XRO Subobject is defined as follows: IPv4 Diversity XRO subobject is defined 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| XRO Type | Length |DI Type|A-Flags|E-Flags| Resvd | |L| XRO Type | Length |DI Type|A-Flags|E-Flags| Resvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Diversity Identifier Source Address | | IPv4 Diversity Identifier Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Diversity Identifier Value | | Diversity Identifier Value |
// ... // // ... //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Similarly, the IPv6 Diversity XRO Subobject is defined as Similarly, the IPv6 Diversity XRO subobject is defined as
follows: 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| XRO Type | Length |DI Type|A-Flags|E-Flags| Resvd | |L| XRO Type | Length |DI Type|A-Flags|E-Flags| Resvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Diversity Identifier source address | | IPv6 Diversity Identifier source address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Diversity Identifier source address (cont.) | | IPv6 Diversity Identifier source address (cont.) |
skipping to change at page 10, line 35 skipping to change at page 10, line 35
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.
XRO Type XRO Type
The value is set to for IPv4 diversity XRO subobject The value is set to TBA1 for the IPv4 diversity XRO
(value to be assigned by IANA). Similarly, The value is subobject (value to be assigned by IANA). Similarly, the
set to for IPv6 diversity XRO Subobject (value to be value is set to TBA2 for the IPv6 diversity XRO subobject
assigned by IANA). (value to be assigned by IANA).
Length Length
The Length contains the total length of the IPv4/ IPv6 Per [RFC4874], the Length contains the total length of the
subobject in bytes, including the Type and Length fields. IPv4/ IPv6 subobject in bytes, including the Type and
The Length is variable, depending on the diversity Length fields. The Length is variable, depending on the
identifier value. diversity identifier value.
Diversity Identifier Type (DI Type) Diversity Identifier Type (DI Type)
Diversity Identifier Type (DI Type) indicates the way the Diversity Identifier Type (DI Type) indicates the way the
reference LSP(s) or route(s) with which diversity is reference LSP(s) or route(s) with which diversity is
required is identified in the IPv4/ IPv6 Diversity required is identified in the IPv4/ IPv6 Diversity
subobjects. The following three DI type values are defined subobjects. The following three DI type values are defined
in this document: in this document:
DI Type value Definition DI Type value Definition
skipping to change at page 12, line 38 skipping to change at page 13, line 4
requested to be node-diverse from the excluded path requested to be node-diverse from the excluded path
specified by the IPv4/ IPv6 Diversity XRO subobject. specified by the IPv4/ IPv6 Diversity XRO subobject.
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 IPv4/ IPv6 Diversity XRO subobject. by the IPv4/ IPv6 Diversity XRO subobject.
Resvd Resvd
This field is reserved. It MUST be set to zero on
This field is reserved. It SHOULD be set to zero on
transmission, and MUST be ignored on receipt for both transmission, and MUST be ignored on receipt for both
IPv4/ IPv6 Diversity XRO subobjects. IPv4/ IPv6 Diversity XRO subobjects.
IPv4 / IPv6 Diversity Identifier source address: IPv4 / IPv6 Diversity Identifier source address:
This field is set to the IPv4/ IPv6 address of the node This field MUST be set to the IPv4/ IPv6 address of the
that assigns the diversity identifier. Depending on the node that assigns the diversity identifier. Depending on
diversity identifier type, the diversity identifier source the diversity identifier type, the diversity identifier
may be a client node, PCE entity or network node. source may be a client node, PCE entity or network node.
Specifically: Specifically:
o When the diversity identifier type is set to "IPv4/ IPv6 o When the diversity identifier type is set to "IPv4/ IPv6
Client Initiated Identifier", the value is set to IPv4/ Client Initiated Identifier", the value is set to IPv4/
IPv6 tunnel sender address of the reference LSP against IPv6 tunnel sender address of the reference LSP against
which diversity is desired. IPv4/ IPv6 tunnel sender which diversity is desired. IPv4/ IPv6 tunnel sender
address is as defined in [RFC3209]. address is as defined in [RFC3209].
o When the diversity identifier type is set to "IPv4/ IPv6 o When the diversity identifier type is set to "IPv4/ IPv6
PCE Allocated Identifier", the value indicates the IPv4/ PCE Allocated Identifier", the value indicates the IPv4/
IPv6 address of the node that assigned the Path Key IPv6 address of the node that assigned the Path Key
identifier and that can return an expansion of the Path identifier and that can return an expansion of the Path
Key or use the Path Key as exclusion in a path Key or use the Path Key as exclusion in a path
computation. The Path Key is defined in [RFC5553]. computation. The Path Key is defined in [RFC5553]. The
PCE-ID is carried in the Identifier Source Address field
of the subobject.
o When the diversity identifier type is set to "IPv4/ IPv6 o When the diversity identifier type is set to "IPv4/ IPv6
Network Assigned Identifier", the value indicates the Network Assigned Identifier", the value indicates the
IPv4/ IPv6 address of the node publishing the Path IPv4/ IPv6 address of the node publishing the Path
Affinity Set (PAS). Affinity Set (PAS).
Diversity Identifier Value: Diversity Identifier Value:
Encoding for this field depends on the diversity identifier Encoding for this field depends on the diversity identifier
type, as defined in the following. type, as defined in the following.
When the diversity identifier type is set to "Client When the diversity identifier type is set to "Client
Initiated Identifier" in IPv4 Diversity XRO subobject, the Initiated Identifier" in IPv4 Diversity XRO subobject, the
diversity identifier value MUST be encoded as follows: diversity identifier value MUST be 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel end point address | | IPv4 tunnel end point address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | Tunnel ID | | Must Be Zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID | | Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | LSP ID | | Must Be Zero | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 15, line 20 skipping to change at page 15, line 30
Assigned Identifier" in IPv4 or IPv6 Diversity XRO Assigned Identifier" in IPv4 or IPv6 Diversity XRO
subobject, the diversity identifier value MUST be encoded subobject, the diversity identifier value MUST be encoded
as follows: 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path Affinity Set (PAS) identifier | | Path Affinity Set (PAS) identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Path affinity Set (PAS) identifier field is a 32-bit The Path Affinity Set (PAS) identifier field is a 32-bit
value that is scoped by, i.e., is only meaningful when value that is scoped by, i.e., is only meaningful when
used in combination with, the Diversity Identifier source used in combination with, the Diversity Identifier source
address field. There are no restrictions on how a node address field. There are no restrictions on how a node
selects a PAS identifier value. Section 1.3. defines the selects a PAS identifier value. Section 1.3 defines the
PAS term and provides context on how values may be PAS term and provides context on how values may be
selected. selected.
2.2. Diversity EXRS Subobject 2.2. 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
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 IPv4 EXRS format is as follows: document. The same type values TBA1 and TBA2 SHALL be used.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| XRO Type | Length |DI Type|A-Flags|E-Flags| Resvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Diversity Identifier source address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Diversity Identifier Value |
// ... //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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 |
// ... //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The meanings of respective fields in EXRS header are as defined
in [RFC4874]. The meanings of respective fields in the Diversity
subobject are as defined earlier in this document for the XRO
Diversity subobject.
2.3. Processing rules for the Diversity XRO and EXRS subobjects 2.3. Processing rules for the Diversity XRO and EXRS subobjects
The procedure defined in [RFC4874] for processing the XRO and The procedure defined in [RFC4874] for processing the XRO and
EXRS is not changed by this document. The processing rules for EXRS is not changed by this document. The processing rules for
the Diversity XRO and EXRS subobjects are similar unless the the Diversity XRO and EXRS subobjects are similar unless the
differences are explicitly described. Similarly, IPv4 and IPv6 differences are explicitly described. Similarly, IPv4 and IPv6
Diversity XRO subobjects and IPv4 and IPv6 Diversity EXRS Diversity XRO subobjects and IPv4 and IPv6 Diversity EXRS
subobjects follow the same processing rules. subobjects follow the same processing rules.
If the processing node cannot recognize the Diversity XRO/ EXRS If the processing node cannot recognize the Diversity XRO/ EXRS
subobject, the node is expected to follow the procedure defined subobject, the node is expected to follow the procedure defined
in [RFC4874]. in [RFC4874].
An XRO/ EXRS object MAY contain multiple Diversity subobjects of An XRO/ EXRS object MAY contain multiple Diversity subobjects of
the same DI Type. E.g., in order to exclude multiple Path Keys, a the same DI Type. E.g., in order to exclude multiple Path Keys, a
node may include multiple Diversity XRO subobjects each with a node MAY include multiple Diversity XRO subobjects each with a
different Path Key. Similarly, in order to exclude the routes different Path Key. Similarly, in order to exclude the routes
taken by multiple LSPs, a node may include multiple Diversity taken by multiple LSPs, a node MAY include multiple Diversity
XRO/ EXRS subobjects each with a different LSP identifier. XRO/ EXRS subobjects each with a different LSP identifier.
Likewise, to exclude multiple PAS identifiers, a node may include Likewise, to exclude multiple PAS identifiers, a node MAY include
multiple Diversity XRO/ EXRS subobjects each with a different PAS multiple Diversity XRO/ EXRS subobjects each with a different PAS
identifier. However, all Diversity subobjects in an XRO/ EXRS identifier. However, all Diversity subobjects in an XRO/ EXRS
MUST contain the same Diversity Identifier Type. If a Path MUST contain the same Diversity Identifier Type. If a Path
message contains an XRO/ EXRS with multiple Diversity subobjects message contains an XRO/ EXRS with multiple Diversity subobjects
of different DI Types, the processing node MUST return a PathErr of different DI Types, 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
"XRO/ EXRS Too Complex" (68/ 69). "XRO/ EXRS Too Complex" (68/ 69).
If the processing node recognize the Diversity XRO/ EXRS If the processing node recognize the Diversity XRO/ EXRS
subobject but does not support the DI type, it MUST return a subobject but does not support the DI type, it MUST return a
PathErr with the error code "Routing Problem" and error value of PathErr with the error code TBA3 "Routing Problem" and error
"Unsupported Diversity Identifier Type". value of "Unsupported Diversity Identifier Type".
The nodes in the domain that perform path computation SHOULD The nodes in the domain that perform path computation SHOULD
process the diversity information signaled in the XRO/ EXRS process the diversity information signaled in the XRO/ EXRS
Diversity subobjects. The transit nodes in a domain and the Diversity subobjects. The transit nodes in a domain and the
domain egress node MAY ignore it. While processing EXRS object, domain egress node SHOULD NOT process the signaled diversity
if a loose-hop expansion results in the creation of another information. While processing EXRS object, if a loose-hop
loose-hop in the outgoing ERO, the processing node MAY include expansion results in the creation of another loose-hop in the
the EXRS in the newly created loose hop for further processing by outgoing ERO, the processing node MAY include the EXRS in the
downstream nodes. newly created loose hop for further processing by downstream
nodes.
The attribute-flags affect the processing of the Diversity XRO/ The attribute-flags affect the processing of the Diversity XRO/
EXRS subobject as follows: EXRS subobject as follows:
o When the "processing node exception" flag is set, the o When the "processing node exception" flag is set, the
exclusion MUST be ignored for the node processing the XRO exclusion MUST be ignored for the node processing the XRO
or EXRS subobject. or EXRS subobject.
o When the "destination node exception" flag is set, the o When the "destination node exception" flag is set, the
exclusion MUST be ignored for the destination node in exclusion MUST be ignored for the destination node in
skipping to change at page 18, line 50 skipping to change at page 18, line 17
- Regardless of whether the path computation is performed - Regardless of whether the path computation is performed
locally or at a remote node (e.g., PCE), the processing node locally or at a remote node (e.g., PCE), the processing node
MUST ensure that any path calculated for the signaled LSP is MUST ensure that any path calculated for the signaled LSP is
diverse from the requested Exclusion Flags. diverse from the requested Exclusion Flags.
- If the excluded path referenced in the XRO subobject is - If the excluded path referenced in the XRO subobject is
unknown to the processing node, the processing node SHOULD unknown to the processing node, the processing node SHOULD
ignore the diversity XRO subobject and SHOULD proceed with the ignore the diversity XRO subobject and SHOULD proceed with the
signaling request. After sending the Resv for the signaled LSP, signaling request. After sending the Resv for the signaled LSP,
the processing node MUST return a PathErr with the error code the processing node MUST return a PathErr with the error code
"Notify Error" (25) and error sub-code "Route reference in "Notify Error" (25) and error sub-code TBA4 "Route of XRO LSP
diversity XRO identifier unknown" (value to be assigned by identifier unknown" (value to be assigned by IANA) for the
IANA) for the signaled LSP. signaled LSP.
- 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 L-flag of the XRO diversity subobject or EXRS diversity If the L-flag of the XRO diversity subobject or EXRS diversity
subobject is set, the processing node proceeds as follows: subobject is set, the processing node proceeds as follows:
- If the Diversity Identifier Type is set to "IPv4/IPv6 Client - If the Diversity Identifier Type is set to "IPv4/IPv6 Client
skipping to change at page 19, line 37 skipping to change at page 19, line 4
Assigned Identifiers", the processing node SHOULD ensure that Assigned Identifiers", the processing node SHOULD ensure that
the path calculated for the signaled LSP is diverse with the path calculated for the signaled LSP is diverse with
respect to the values associated with the PAS identifier and respect to the values associated with the PAS identifier and
Diversity Identifier source address fields. Diversity Identifier source address fields.
- 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.
After sending the Resv for the signaled LSP, it MUST return a After sending the Resv for the signaled LSP, it MUST 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 satisfy Exclude Route" (value: to be sub-code TBA5 "Failed to satisfy Exclude Route" (value: to be
assigned by IANA) to the source node. assigned by IANA) to the source node.
If, subsequent to the initial signaling of a diverse LSP, an If, subsequent to the initial signaling of a diverse LSP, an
excluded path referenced in the XRO subobject becomes known to excluded path referenced in the XRO subobject becomes known to
the processing node, or a change in the excluded path becomes the processing node, or a change in the excluded path becomes
known to the processing node, the processing node MUST re- known to the processing node, the processing node MUST re-
evaluate the exclusion and diversity constraints requested by the evaluate the exclusion and diversity constraints requested by the
diverse LSP to determine whether they are still satisfied. diverse LSP to determine whether they are still satisfied.
If, subsequent to the initial signaling of a diverse LSP, the If, subsequent to the initial signaling of a diverse LSP, the
skipping to change at page 20, line 16 skipping to change at page 19, line 30
processing node MUST send a PathErr message for the diverse LSP processing node MUST send a PathErr message for the diverse LSP
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). The Path_State_Removed "Route blocked by Exclude Route" (67). The Path_State_Removed
flag (PSR) [RFC3473] MUST NOT be set. A source node receiving a flag (PSR) [RFC3473] MUST NOT be set. A source node receiving a
PathErr message with this error code and sub-code combination PathErr message with this error code and sub-code combination
SHOULD take appropriate actions to migrate to a compliant path. SHOULD take appropriate actions to migrate to a compliant path.
- If the L-flag was set in the original exclusion, the - If the L-flag was set in the original exclusion, the
processing node MUST send a PathErr message for the diverse LSP processing node MUST send a PathErr message for the diverse LSP
with the error code "Notify Error" (25) and a new error sub- with the error code "Notify Error" (25) and a new error sub-
code "compliant path exists" (value: to be assigned by IANA). code TBA6 "Compliant path exists" (value: to be assigned by
The PSR flag MUST NOT be set. A source node receiving a PathErr IANA). The PSR flag MUST NOT be set. A source node receiving a
message with this error code and sub-code combination MAY PathErr message with this error code and sub-code combination
signal a new LSP to migrate the compliant path. MAY signal a new LSP to migrate the compliant path.
If, subsequent to the initial signaling of a diverse LSP, the If, subsequent to the initial signaling of a diverse LSP, the
requested exclusion constraints for the diverse LSP are no longer requested exclusion constraints for the diverse LSP are no longer
satisfied and no alternative path for the diverse LSP that can satisfied and no alternative path for the diverse LSP that can
satisfy those constraints exists, then: satisfy those constraints exists, then:
- If the L-flag was not set in the original exclusion, the - If the L-flag was not set in the original exclusion, the
processing node MUST send a PathErr message for the diverse LSP processing node MUST send a PathErr message for the diverse LSP
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). The PSR flag MUST be "Route blocked by Exclude Route" (67). The PSR flag MUST be
set. set.
- If the L-flag was set in the original exclusion, the - If the L-flag was set in the original exclusion, the
processing node MUST send a PathErr message for the diverse LSP processing node MUST send a PathErr message for the diverse LSP
with the error code error code "Notify Error" (25) and error with the error code error code "Notify Error" (25) and error
sub-code "Failed to satisfy Exclude Route" (value: to be sub-code TBA5 "Failed to satisfy Exclude Route" (value: to be
assigned by IANA). The PSR flag MUST NOT be set. The source assigned by IANA). The PSR flag MUST NOT be set. The source
node MAY take no action and keep the LSP along the non- node MAY take no action and keep the LSP along the non-
compliant path. compliant path.
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].
The diversity mechanism defined in this document, relies on the
new diversity subobject that is carried in the XRO or EXRS,
respectively. In section 7 of [RFC4874], it is stated that the
XRO could be considered for removal from the Path message due to
security concerns for example at administrative boundaries. In
this case, the diversity subobject would also be removed. Hence,
the diversity subobject must be kept while other subobjects may
be removed.
4. IANA Considerations 4. IANA Considerations
IANA is requested to administer the assignment of new values IANA is requested to administer the assignment of new values
defined in this document and summarized in this section. defined in this document and summarized in this section.
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
skipping to change at page 21, line 28 skipping to change at page 21, line 8
parameters.xhtml#rsvp-parameters-94) parameters.xhtml#rsvp-parameters-94)
Subobject Description Subobject Type Subobject Description Subobject Type
------------------------ -------------- ------------------------ --------------
IPv4 Diversity subobject TBA1 IPv4 Diversity subobject TBA1
IPv6 Diversity subobject TBA2 IPv6 Diversity subobject TBA2
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. (see: http://www.iana.org/assignments/rsvp- subobjects. (EXPLICIT_ROUTE see:
parameters/rsvp-parameters.xhtml#rsvp-parameters-24) http://www.iana.org/assignments/rsvp-parameters/rsvp-
parameters.xhtml#rsvp-parameters-24). The same numeric subobject
type values TBA1 and TBA2 are being requested for the two new
EXRS subobjects.
4.3. New RSVP error sub-codes 4.3. 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 "Routing Problem" (24) (see [RFC3209]) the For Error Code "Routing Problem" (24) (see [RFC3209]) the
following sub-codes are defined. (see: following sub-codes are defined. (see:
http://www.iana.org/assignments/rsvp-parameters/rsvp- http://www.iana.org/assignments/rsvp-parameters/rsvp-
parameters.xhtml#rsvp-parameters-105) parameters.xhtml#rsvp-parameters-105)
skipping to change at page 22, line 30 skipping to change at page 22, line 17
+-------------+----------------------------+---------------+ +-------------+----------------------------+---------------+
| TBA4 | Route of XRO LSP | This document | | TBA4 | Route of XRO LSP | This document |
| | identifier unknown | | | | identifier unknown | |
| TBA5 | Failed to satisfy | This document | | TBA5 | Failed to satisfy | This document |
| | Exclude Route | | | | Exclude Route | |
| TBA6 | Compliant path exists | This document | | TBA6 | Compliant path exists | This document |
+-------------+----------------------------+---------------+ +-------------+----------------------------+---------------+
5. Acknowledgements 5. Acknowledgements
The authors would like to thank Xihua Fu for contribution to The authors would like to thank Xihua Fu for his contributions.
the development of this document. The authors would also like The authors also would like to thank Luyuan Fang and Walid Wakim
to thank Luyuan Fang and Walid Wakim for their review comments. for their review comments.
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
skipping to change at page 23, line 30 skipping to change at page 23, line 17
[RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter,
"Generalized Multiprotocol Label Switching (GMPLS) "Generalized Multiprotocol Label Switching (GMPLS)
User-Network Interface (UNI): Resource ReserVation User-Network Interface (UNI): Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Support for the Protocol-Traffic Engineering (RSVP-TE) Support for the
Overlay Model", RFC 4208, October 2005. Overlay Model", RFC 4208, October 2005.
[RFC4920] Farrel, A., Ed., Satyanarayana, A., Iwata, A., Fujita, [RFC4920] Farrel, A., Ed., Satyanarayana, A., Iwata, A., Fujita,
N., and G. Ash, "Crankback Signaling Extensions for N., and G. Ash, "Crankback Signaling Extensions for
MPLS and GMPLS RSVP-TE", RFC 4920, July 2007. MPLS and GMPLS RSVP-TE", RFC 4920, July 2007.
[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-teas-rsvp-te-srlg-collect-04, Information", draft-ietf-teas-rsvp-te-srlg-collect-08,
in expert review. in expert review.
[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.
[RFC5251] D. Fedyk, Ed., Y. Rekhter, Ed., D. Papadimitriou, [RFC5251] Fedyk, D. (Ed.), Rekhter, Y. (Ed.), Papadimitriou, D.,
R. Rabbat, L. Berger, "Layer 1 VPN Basic Mode", Rabbat, R., and Berger, L., "Layer 1 VPN Basic Mode",
RFC 5251, July 2008. RFC 5251, July 2008.
[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.
Contributors' Addresses Contributors' Addresses
Igor Bryskin Igor Bryskin
ADVA Optical Networking Huawei Technologies
Email: ibryskin@advaoptical.com Email: Igor.Bryskin@huawei.com
Daniele Ceccarelli Daniele Ceccarelli
Ericsson Ericsson
Email: Daniele.Ceccarelli@ericsson.com Email: Daniele.Ceccarelli@ericsson.com
Dhruv Dhody Dhruv Dhody
Huawei Technologies Huawei Technologies
Email: dhruv.ietf@gmail.com Email: dhruv.ietf@gmail.com
Oscar Gonzalez de Dios Oscar Gonzalez de Dios
 End of changes. 41 change blocks. 
127 lines changed or deleted 98 lines changed or added

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