CCAMP Working Group Xian Zhang
Internet Draft Fatai Zhang
Category: Standards track Huawei
O. Gonzalez de Dios
Telefonica I+D
Igor Bryskin
ADVA Optical Networking
Dhruv Dhody
Huawei
Expires: August 13, 2014 February 14, 2014
Extensions to Resource ReSerVation Protocol-Traffic Engineering (RSVP-
TE) to Support Route Exclusion Using Path Key Subobject
draft-zhang-ccamp-route-exclusion-pathkey-01.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 13, 2014.
Zhang et al Expires August 2014 [Page 1]
draft-zhang-ccamp-route-exclusion-pathkey-01.txt February 2014
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Abstract
This document extends the Resource ReSerVation Protocol-Traffic
Engineering (RSVP-TE) eXclude Route Object (XRO) and Explicit
eXclusion Route Subobject (EXRS) within Explicit Route Object (ERO)
to support specifying route exclusion requirement using Path Key
Subobject (PKS).
Table of Contents
1. Introduction ................................................ 3
1.1. Example Use ............................................ 3
2. RSVP-TE Extensions .......................................... 4
2.1. Path Key Subobject (PKS)................................ 4
2.2. PKS Processing Rules.................................... 5
3. Other considerations......................................... 6
3.1. Path-Key Retention and Reuse............................ 6
3.2. Path-Key Uniqueness..................................... 7
3.3. PKS Update ............................................. 7
4. Manageability Considerations .................................7
4.1. Control of Function through Configuration and Policy.....7
5. Security Considerations...................................... 8
6. IANA Considerations ......................................... 8
Zhang et al Expires August 2014 [Page 2]
draft-zhang-ccamp-route-exclusion-pathkey-01.txt February 2014
6.1. New Subobject Type...................................... 8
6.2. New Error Code ......................................... 8
7. Acknowledgments ............................................. 9
8. References .................................................. 9
8.1. Normative References.................................... 9
8.2. Informative References.................................. 9
9. Contributors ................................................ 9
10. Authors' Addresses ......................................... 9
1. Introduction
[RFC5520] defines the concept of a Path Key for confidentiality in a
multi-domain environment. This can be used by a Path Computation
Element (PCE) in place of a segment of a path that it wishes to keep
confidential. The Path Key can be signaled in Resource ReSerVation
Protocol-Traffic Engineering (RSVP-TE) protocol by placing it in an
Explicit Route Object (ERO) as described in [RFC5553].
When establishing a set of LSPs to provide protection services
[RFC4427], it is often desirable that the LSPs should take different
paths through the network. This can be achieved by path computation
entities that have full end-to-end visibility, but it is more
complicated in multi-domain environments when segments of the path
may be hidden so that they are not visible outside the domain they
traverse.
This document describes how the Path Key object can be used in the
RSVP-TE eXclude Route Object (XRO), and the Explicit eXclusion Route
subobject (EXRS) of the ERO in order to facilitate path hiding, but
allow diverse end-to-end paths to be established in multi-domain
environments.
1.1. Example Use
Figure 1 shows a simple network with two domains. It is desired to
set up a pair of path-disjoint LSPs from the source in Domain 1 to
the destination in Domain 2, but the domains keep strict
confidentiality about all path and topology information.
The first LSP will be signaled by the source with ERO {A, B, loose
Dst} and will be set up with the path {Src, A, B, U, V, W, Dst}. But
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
this limited information, the source is unable to include enough
detail in the ERO of the second LSP to avoid it taking, for example,
the path {Src, C, D, X, V, W, Dst} which is not path-disjoint.
Zhang et al Expires August 2014 [Page 3]
draft-zhang-ccamp-route-exclusion-pathkey-01.txt February 2014
--------------------- -----------------------------
| Domain 1 | | Domain 2 |
| | | |
| --- --- | | --- --- --- |
| | A |--| B |--+--+--| U |--| V |---| W | |
| / --- --- | | --- --- --- \ |
| ---/ | | / / \--- |
| |Src| | | / / |Dst| |
| ---\ | | / / /--- |
| \ --- --- | | --- / --- / --- / |
| | C |--| D |--+--+--| X |---| Y |--| Z | |
| --- --- | | --- --- --- |
| | | |
--------------------- -----------------------------
Figure 1: A Simple Multi-Domain Network
In order to improve the outcome, node U can replace the path segment
{U, V, W} in the RRO with a Path Key Suboject. The Path Key
Subobject assigns an identifier to the key and also indicates that
it was node U that made the replacement.
With this additional information, the source is able to signal the
second LSP with ERO set to {C, D, exclude Path Key(EXRS), loose Dst}.
When the signaling message reaches node X, it can consult node U to
expand the Path Key and so know to 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 Path Key.
This example uses a PCE deployed in each border router, having at
least the capability to expand PKS. Other deployment scenarios
(Domain PCE, PCE being part of the Management system) may be used.
2. RSVP-TE Extensions
This section defines the Path Key Subobject that can be either in
the XRO object or Explicit eXclusion Route subobject (EXRS) as
defined in [RFC4874].
2.1. Path Key Subobject (PKS)
The IPv4 PKS has the same format as defined in [RFC5553] and is
detailed as below:
Zhang et al Expires August 2014 [Page 4]
draft-zhang-ccamp-route-exclusion-pathkey-01.txt February 2014
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 | Path Key |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCE-ID (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The meaning of the field Length and Path Key is defined in [RFC5553].
L: 0 indicates that the path or path segment hidden with the Path
Key specified MUST be excluded. 1 indicates that the path or path
segment hidden with the Path Key specified SHOULD be avoided.
Type: sub-object type for XRO Path Key; TBD.
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 an exclusion in a path computation. Note this draft
does not confine whether it is the network element or a dedicated
server for path key generation and decoding.
Similarly, the format of IPv6 PKS 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 | Path Key |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCE-ID (16 bytes) |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.2. PKS Processing Rules
The exclude route list is encoded as a series of subobjects
contained in an EXCLUDE_ROUTE object or an EXRS of the ERO. Multiple
Path-Keys may be included in XRO or EXRO of ERO if more than segment
of a path are kept hidden during diverse path establishment. The
procedure defined in [RFC4874] for processing XRO and EXRS is not
changed by this document.
Irrespective of the L flag, if the node, receiving the PKS, cannot
recognize the subobject, it will react according to [RFC4874] and
SHOULD ignore the constraint.
Zhang et al Expires August 2014 [Page 5]
draft-zhang-ccamp-route-exclusion-pathkey-01.txt February 2014
Otherwise, if it decodes the PKS 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/value
combination "Routing Problem" / "Route Blocked by Exclude Route".
-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" /
"Fail to find diversified path" (TBD).
If it cannot decode the PKS, the error handling procedure defined in
Section 3.1 of [RFC5553] is not changed by this document.
This mechanism can work with all the PKS resolution mechanism, 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 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.
3. Other considerations
3.1. Path-Key Retention and Reuse
The use of the path key relies on the availability of a PCE function
supporting [RFC5520] functionality.
Following [RFC4655] a simple deployment option is when the PCE
function is collocated with each border domain node generating the
RRO. This collocated PCE functionality can be restricted to only
serve the PKS resolution. This PCE function is only required to be
accessible to the nodes excluding this PKS, so this can be
restricted to one domain. This option can very easily tie the
lifetime of the PKS to the lifetime of the LSP.
Alternatively, if a dedicated server, such as a PCE, is in charge of
this, it may need to be explicitly informed of the LSP tear-down in
order to recycle the path key allocated already. This can be easily
supported by a stateful PCE [Stateful-PCE]. Note this draft does not
confine the methods for path key generation and decoding.
Last, options including allowing a LSR can use the PKS information
to index a Path Segment previously supplied to it by the entity that
Zhang et al Expires August 2014 [Page 6]
draft-zhang-ccamp-route-exclusion-pathkey-01.txt February 2014
originated the PKS, for example the LSR that inserted the PKS in the
RRO or a management system, can also be used.
3.2. Path-Key Uniqueness
In the CCAMP mailing list, there is concern about whether 16-bit
Path key is still enough and future proof. This can be easily solved
by confining the scope of a path key. If an ingress node is
responsible for managing the Path Key, it should not be an issue
since the LSP across domains do not expected to be larger than 65535.
On the other hand, if a dedicated entity, such as a PCE server, is
used to allocate and recycle the Path Key, it is advised to allocate
the Path Key per ingress node basis to avoid the limitation of Path
Key numbers facing a domain-based allocation space. These are only
illustrative examples and other methods that can guarantee the
uniqueness of Path-Key are not precluded.
3.3. PKS Update
When the information of a path is changed, the LSPs using that path
and corresponding PKS should be aware of the changes. The
procedures defined in Section 4.4.3 of RFC 3209 [RFC3209] MUST be
used to refresh the PKS information if the PKS change is to be
communicated to other nodes according to the local node's policy.
If local policy is that the PKS change should be suppressed or would
result in no change to the PKS expansion, the node does not need to
send an update. This procedure allows for ingress node to react on
path change.
4. Manageability Considerations
4.1. Control of Function through Configuration and Policy
In addition to the set of policies described in [RFC5553] the
following policies (are local and domain-wide) SHOULD be available
for configuration in an implementation:
- Handling a XRO or EXRS containing a PKS. As described in Section
2.2, an LSR that receives a Path message containing a PKS exclusion
can be configured to reject the Path message according to policy.
- Hiding of reason codes. The policy described in [RFC5553] section
5.1 is also applicable to policies for PKS in XRO or EXRS.
This document makes no other new management consideration to RSVP
and PCE, the existing consideration applies.
Zhang et al Expires August 2014 [Page 7]
draft-zhang-ccamp-route-exclusion-pathkey-01.txt February 2014
5. Security Considerations
The use of path keys proposed in this draft allows nodes to hide
parts of the path as it is signaled. This can be used to improve the
confidentially of the LSP setup. Moreover, it may serve to improve
security of the control plane for the LSP as well as data plane
traffic carried on this LSP. However, the benefits of using path key
are lost unless there is an appropriate access control of any tool
that allows expansion of the path key.
6. IANA Considerations
6.1. New Subobject Type
IANA registry: RSVP PARAMETERS
Subsection: Class Names, Class Numbers, and Class Types
This document introduces two new subobjects for the EXCLUDE_ROUTE
object [RFC4874], C-Type 1.
Subobject Type Subobject Description
-------------- ---------------------
64(TBD by IANA) IPv4 Path Key Subobject
65(TBD By IANA) IPv6 Path Key Subobject
Note: [RFC5520] defines the PKS for use in PCEP. The above number
suggestions for use in RSVP-TE follow that assigned for the PKS in
PCEP [RFC5520].
6.2. New Error Code
IANA registry: RSVP PARAMETERS
Subsection: Error Codes and Globally-Defined Error Value Sub-Codes
New Error Values sub-codes have been registered for the Error Code
'Notify Error' (25).
TBD = "Fail to find diversified path"
Zhang et al Expires August 2014 [Page 8]
draft-zhang-ccamp-route-exclusion-pathkey-01.txt February 2014
7. Acknowledgments
The authors would like to thank John Drake, Daniele Ceccarelli and
Zafar Ali for their comments and dicussions.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to indicate
requirements levels", RFC 2119, March 1997.
[RFC3209] D. Awduche et al, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC3209, December 2001.
[RFC4874] CY. Lee, A. Farrel, S. De Cnodder, "Exclude Routes -
Extension to Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE), RFC4874, April 2007.
[RFC5553] A. Farrel, Ed., "Resource Reservation Protocol (RSVP)
Extensions for Path Key Support", RFC5553, May 2009.
8.2. Informative References
[RFC5520] R. Bradford, Ed., "Preserving Topology Confidentiality
in Inter-Domain Path Computation Using a Path-Key-Based
Mechanism", RFC5520, April 2009.
[RFC4427] E. Mannie, Ed., "Recovery (Protection and Restoration)
Terminology for Generalized Multi-Protocol Label
Switching (GMPLS)", RFC4427, March 2006.
[Stateful-PCE] Crabbe, E., Medved, J., Minei, I., and R. Varga,
"PCEP Extensions for Stateful PCE", draft-ietf-pce-
stateful-pce-06 (work in progress), August 2013.
9. Contributors
Cyril
cyril.margaria@gmail.com
10. Authors' Addresses
Zhang et al Expires August 2014 [Page 9]
draft-zhang-ccamp-route-exclusion-pathkey-01.txt February 2014
Xian Zhang
Huawei Technologies
Email: zhang.xian@huawei.com
Fatai Zhang
Huawei Technologies
Email: zhangfatai@huawei.com
Oscar Gonzalez de Dios
Telefonica I+D
Don Ramon de la Cruz
Madrid, 28006
Spain
Phone: +34 913328832
Email: ogondio@tid.es
Igor Bryskin
ADVA Optical Networking
Email: ibryskin@advaoptical.com
Dhruv Dhody
Huawei Technologies
Leela Palace
Bangalore, Karnataka 560008
INDIA
EMail: dhruv.ietf@gmail.com
Zhang et al Expires August 2014 [Page 10]