draft-ietf-ccamp-rsvp-te-srlg-collect-08.txt   draft-ietf-ccamp-rsvp-te-srlg-collect-09.txt 
Network Working Group F. Zhang, Ed. Network Working Group F. Zhang, Ed.
Internet-Draft Huawei Internet-Draft Huawei
Intended status: Standards Track O. Gonzalez de Dios, Ed. Intended status: Standards Track O. Gonzalez de Dios, Ed.
Expires: April 26, 2015 Telefonica Global CTO Expires: April 30, 2015 Telefonica Global CTO
D. Li D. Li
Huawei Huawei
C. Margaria C. Margaria
M. Hartley M. Hartley
Z. Ali Z. Ali
Cisco Cisco
October 23, 2014 October 27, 2014
RSVP-TE Extensions for Collecting SRLG Information RSVP-TE Extensions for Collecting SRLG Information
draft-ietf-ccamp-rsvp-te-srlg-collect-08 draft-ietf-ccamp-rsvp-te-srlg-collect-09
Abstract Abstract
This document provides extensions for the Resource ReserVation This document provides extensions for the Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) to support automatic Protocol-Traffic Engineering (RSVP-TE) to support automatic
collection of Shared Risk Link Group (SRLG) information for the TE collection of Shared Risk Link Group (SRLG) information for the TE
link formed by a Label Switched Path (LSP). link formed by a Label Switched Path (LSP).
Status of This Memo Status of This Memo
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 26, 2015. This Internet-Draft will expire on April 30, 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 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
skipping to change at page 2, line 34 skipping to change at page 2, line 34
5. Signaling Procedures . . . . . . . . . . . . . . . . . . . . 7 5. Signaling Procedures . . . . . . . . . . . . . . . . . . . . 7
5.1. SRLG Collection . . . . . . . . . . . . . . . . . . . . . 7 5.1. SRLG Collection . . . . . . . . . . . . . . . . . . . . . 7
5.2. SRLG Update . . . . . . . . . . . . . . . . . . . . . . . 9 5.2. SRLG Update . . . . . . . . . . . . . . . . . . . . . . . 9
5.3. Compatibility . . . . . . . . . . . . . . . . . . . . . . 9 5.3. Compatibility . . . . . . . . . . . . . . . . . . . . . . 9
6. Manageability Considerations . . . . . . . . . . . . . . . . 9 6. Manageability Considerations . . . . . . . . . . . . . . . . 9
6.1. Policy Configuration . . . . . . . . . . . . . . . . . . 9 6.1. Policy Configuration . . . . . . . . . . . . . . . . . . 9
6.2. Coherent SRLG IDs . . . . . . . . . . . . . . . . . . . . 9 6.2. Coherent SRLG IDs . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8.1. RSVP Attribute Bit Flags . . . . . . . . . . . . . . . . 10 8.1. RSVP Attribute Bit Flags . . . . . . . . . . . . . . . . 10
8.2. ROUTE_RECORD Object . . . . . . . . . . . . . . . . . . . 10 8.2. ROUTE_RECORD Object . . . . . . . . . . . . . . . . . . . 11
8.3. Policy Control Failure Error subcodes . . . . . . . . . . 11 8.3. Policy Control Failure Error subcodes . . . . . . . . . . 11
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . 11 10.1. Normative References . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . 12 10.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
It is important to understand which TE links in the network might be It is important to understand which TE links in the network might be
skipping to change at page 4, line 25 skipping to change at page 4, line 25
first connection. first connection.
As SRLG information is normally not shared between the provider As SRLG information is normally not shared between the provider
network and the client network, i.e., between PE and CE devices, the network and the client network, i.e., between PE and CE devices, the
challenge is how to solve the diversity problem when a CE is dual- challenge is how to solve the diversity problem when a CE is dual-
homed. For example, CE1 in Figure 1 may have requested an LSP1 to homed. For example, CE1 in Figure 1 may have requested an LSP1 to
CE2 via PE1 that is routed via PE3 to CE2. CE1 can then subsequently CE2 via PE1 that is routed via PE3 to CE2. CE1 can then subsequently
request an LSP2 to CE2 via PE2 with the constraint that it needs to request an LSP2 to CE2 via PE2 with the constraint that it needs to
be maximally SRLG disjoint with respect to LSP1. PE2, however, does be maximally SRLG disjoint with respect to LSP1. PE2, however, does
not have any SRLG information associated with LSP1, which is needed not have any SRLG information associated with LSP1, which is needed
as input for its constrained-based path computation function. If CE1 as input for its constraint-based path computation function. If CE1
is capable of retrieving the SRLG information associated with LSP1 is capable of retrieving the SRLG information associated with LSP1
from PE1, it can pass this information to PE2 as part of the LSP2 from PE1, it can pass this information to PE2 as part of the LSP2
setup request (RSVP PATH message), and PE2 can now calculate a path setup request (RSVP PATH message), and PE2 can now calculate a path
for LSP2 that is SRLG disjoint with respect to LSP1. The SRLG for LSP2 that is SRLG disjoint with respect to LSP1. The SRLG
information associated with LSP1 can already be retrieved when LSP1 information associated with LSP1 can already be retrieved when LSP1
is setup or at any time before LSP2 is setup. is setup or at any time before LSP2 is setup.
The RSVP extensions for collecting SRLG information defined in this The RSVP extensions for collecting SRLG information defined in this
document make it possible to retrieve SRLG information for an LSP and document make it possible to retrieve SRLG information for an LSP and
hence solve the dual-homing LSP diversity problem. When CE1 sends hence solve the dual-homing LSP diversity problem. When CE1 sends
the setup request for LSP2 to PE2, it can also request the collection the setup request for LSP2 to PE2, it can also request the collection
of SRLG information for LSP2 and send that information to PE1. This of SRLG information for LSP2 and send that information to PE1. This
will ensure that the two paths for the two LSPs remain mutually will ensure that the two paths for the two LSPs remain mutually
diverse, which is important, when the provider network is capable to diverse, which is important, when the provider network is capable to
restore connections that failed due to a network failure (fiber cut) restore connections that failed due to a network failure (fiber cut)
in the provider network. in the provider network.
It shall be noted that the knowledge of SRLG information even for Note that the knowledge of SRLG information even for multiple LSPs
multiple LSPs does not allow a CE devices to derive the provider does not allow a CE devices to derive the provider network topology
network topology based on the collected SRLG information. based on the collected SRLG information.
2. Requirements Language 2. Requirements Language
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].
3. RSVP-TE Requirements 3. RSVP-TE Requirements
3.1. SRLG Collection Indication 3.1. SRLG Collection Indication
skipping to change at page 7, line 8 skipping to change at page 7, line 8
before the node IP address or link identifier. The SRLG-sub-object before the node IP address or link identifier. The SRLG-sub-object
SHOULD be pushed after the Attribute subobject, if present, and after SHOULD be pushed after the Attribute subobject, if present, and after
the LABEL subobject, if requested. the LABEL subobject, if requested.
RFC 5553 [RFC5553] describes mechanisms to carry a PKS (Path Key Sub- RFC 5553 [RFC5553] describes mechanisms to carry a PKS (Path Key Sub-
object) in the RRO so as to facilitate confidentiality in the object) in the RRO so as to facilitate confidentiality in the
signaling of inter-domain TE LSPs, and allows the path segment that signaling of inter-domain TE LSPs, and allows the path segment that
needs to be hidden (that is, a Confidential Path Segment (CPS)) to be needs to be hidden (that is, a Confidential Path Segment (CPS)) to be
replaced in the RRO with a PKS. If the CPS contains SRLG Sub- replaced in the RRO with a PKS. If the CPS contains SRLG Sub-
objects, these MAY be retained in the RRO by adding them again after objects, these MAY be retained in the RRO by adding them again after
the PKS Sub-object in the RRO. the PKS Sub-object in the RRO. The CPS is defined in RFC 5520
[RFC5520]
A node MUST NOT push a SRLG sub-object in the RECORD_ROUTE without A node MUST NOT push a SRLG sub-object in the RECORD_ROUTE without
also pushing either a IPv4 sub-object, a IPv6 sub-object, a also pushing either a IPv4 sub-object, a IPv6 sub-object, a
Unnumbered Interface ID sub-object or a Path Key sub-object. Unnumbered Interface ID sub-object or a Path Key sub-object.
The rules of the processing of the LSP_REQUIRED_ATTRIBUTES, The rules of the processing of the LSP_REQUIRED_ATTRIBUTES,
LSP_ATTRIBUTE and ROUTE_RECORD Objects are not changed. LSP_ATTRIBUTE and ROUTE_RECORD Objects are not changed.
5. Signaling Procedures 5. Signaling Procedures
skipping to change at page 7, line 46 skipping to change at page 7, line 47
When a node receives a Path message which carries an LSP_ATTRIBUTES When a node receives a Path message which carries an LSP_ATTRIBUTES
Object and the SRLG Collection Flag set, if local policy determines Object and the SRLG Collection Flag set, if local policy determines
that the SRLG information is not to be provided to the endpoints, the that the SRLG information is not to be provided to the endpoints, the
Path message SHOULD NOT be rejected due to SRLG recording restriction Path message SHOULD NOT be rejected due to SRLG recording restriction
and the Path message SHOULD be forwarded without any SRLG sub- and the Path message SHOULD be forwarded without any SRLG sub-
object(s) in the RRO of the corresponding outgoing Path message. object(s) in the RRO of the corresponding outgoing Path message.
If local policy permits the recording of the SRLG information, the If local policy permits the recording of the SRLG information, the
processing node SHOULD add local SRLG information, as defined below, processing node SHOULD add local SRLG information, as defined below,
to the RRO of the corresponding outgoing Path message. It then to the RRO of the corresponding outgoing Path message. The
forwards the Path message to the next node in the downstream processing node MAY add multiple SRLG sub-objects to the RRO if
direction. necesary. It then forwards the Path message to the next node in the
downstream direction.
If the addition of SRLG information to the RRO would result in the
RRO exceeding its maximum possible size or becoming too large for the
Path message to contain it, the requested SRLGs MUST NOT be added.
If the SRLG collection request was contained in an
LSP_REQUIRED_ATTRIBUTES Object, the processing node MUST behave as
specified by RFC 3209 [RFC3209] and drop the RRO from the Path
message entirely. If the SRLG collection request was contained in an
LSP_ATTRIBUTES Object, the processing node MAY omit some or all of
the requested SRLGs from the RRO; otherwise it MUST behave as
specified by RFC 3209 [RFC3209] and drop the RRO from the Path
message entirely.
Following the steps described above, the intermediate nodes of the Following the steps described above, the intermediate nodes of the
LSP can collect the SRLG information in the RRO during the processing LSP can collect the SRLG information in the RRO during the processing
of the Path message hop by hop. When the Path message arrives at the of the Path message hop by hop. When the Path message arrives at the
egress node, the egress node receives SRLG information in the RRO. egress node, the egress node receives SRLG information in the RRO.
Per RFC 3209 [RFC3209], when issuing a Resv message for a Path Per RFC 3209 [RFC3209], when issuing a Resv message for a Path
message which contains an RRO, an egress node initiates the RRO message which contains an RRO, an egress node initiates the RRO
process by adding an RRO to the outgoing Resv message. The process by adding an RRO to the outgoing Resv message. The
processing for RROs contained in Resv messages then mirrors that of processing for RROs contained in Resv messages then mirrors that of
the Path messages. the Path messages.
When a node receives a Resv message for an LSP for which SRLG When a node receives a Resv message for an LSP for which SRLG
Collection is specified, if local policy determines that the SRLG Collection is specified, then when local policy allows recording SRLG
information is not to be provided to the endpoints, if the SRLG- information, the node SHOULD add SRLG information, to the RRO of the
recording request was in a LSP_REQUIRED_ATTRIBUTES object, then a corresponding outgoing Resv message, as specified below. When the
ResvErr with Error code 2 (policy) and Error subcode "SRLG Recording Resv message arrives at the ingress node, the ingress node can
Rejected" (temporary value 21, an early allocation of the value has extract the SRLG information from the RRO in the same way as the
been made by IANA, see Section 8.3 for more details) MUST be sent. egress node.
If the request was in a LSP_ATTRIBUTES object, then a ResvErr SHOULD
NOT be generated, but SRLG information MUST NOT be added in the RRO.
When local policy allows recording SRLG information, the node SHOULD
add SRLG information, as defined below, to the RRO of the
corresponding outgoing Resv message. When the Resv message arrives
at the ingress node, the ingress node can get the SRLG information
from the RRO in the same way as the egress node.
Note that a link's SRLG information for the upstream direction cannot Note that a link's SRLG information for the upstream direction cannot
be assumed to be the same as that in the downstream. be assumed to be the same as that in the downstream.
o For Path and Resv messages for a unidirectional LSP, a node SHOULD o For Path and Resv messages for a unidirectional LSP, a node SHOULD
include SRLG sub-objects in the RRO for the downstream data link include SRLG sub-objects in the RRO for the downstream data link
only. only.
o For Path and Resv messages for a bidirectional LSP, a node SHOULD o For Path and Resv messages for a bidirectional LSP, a node SHOULD
include SRLG sub-objects in the RRO for both the upstream data include SRLG sub-objects in the RRO for both the upstream data
skipping to change at page 12, line 5 skipping to change at page 12, line 14
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic (GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC5420] Farrel, A., Papadimitriou, D., Vasseur, JP., and A. [RFC5420] Farrel, A., Papadimitriou, D., Vasseur, JP., and A.
Ayyangarps, "Encoding of Attributes for MPLS LSP Ayyangarps, "Encoding of Attributes for MPLS LSP
Establishment Using Resource Reservation Protocol Traffic Establishment Using Resource Reservation Protocol Traffic
Engineering (RSVP-TE)", RFC 5420, February 2009. Engineering (RSVP-TE)", RFC 5420, February 2009.
[RFC5520] Bradford, R., Vasseur, JP., and A. Farrel, "Preserving
Topology Confidentiality in Inter-Domain Path Computation
Using a Path-Key-Based Mechanism", RFC 5520, April 2009.
[RFC5553] Farrel, A., Bradford, R., and JP. Vasseur, "Resource [RFC5553] Farrel, A., Bradford, R., and JP. Vasseur, "Resource
Reservation Protocol (RSVP) Extensions for Path Key Reservation Protocol (RSVP) Extensions for Path Key
Support", RFC 5553, May 2009. Support", RFC 5553, May 2009.
10.2. Informative References 10.2. Informative References
[RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in [RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in
Support of Generalized Multi-Protocol Label Switching Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4202, October 2005. (GMPLS)", RFC 4202, October 2005.
 End of changes. 11 change blocks. 
26 lines changed or deleted 37 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/