CCAMP Working Group Zafar Ali
Internet Draft George Swallow
Intended status: Standard Track Clarence Filsfils
Expires: January 14, 2014 Matt Hartley
Ori Gerstel
Cisco Systems
Kenji Kumaki
KDDI Corporation
Ruediger Kunze
Deutsche Telekom AG
July 15, 2013
Include Routes - Extension to
Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)
draft-ali-ccamp-rsvp-te-include-route-04.txt
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current
Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on January 14, 2014.
Copyright Notice
Copyright (c) 2012 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
Ali, Swallow, Filsfils, et al Expires January 2014 [Page 1]
Internet-Draft draft-ali-ccamp-rsvp-te-include-route-04.txt
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.
Abstract
There are scenarios that require two or more LSPs or segments of
LSPs to follow same route in the network. This document specifies
methods to communicate route inclusions along the loose hops during
path setup using the Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) protocol.
Conventions used in this document
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 RFC 2119
[RFC2119].
Table of Contents
Copyright Notice.....................................................1
1. Introduction......................................................2
2. RSVP-TE signaling extensions......................................4
2.1. IPv4 Point-to-Point LSP ERO subobject.....................4
2.2. IPv6 Point-to-Point LSP ERO subobject.....................6
2.3. Processing rules for LSP ERO subobjects...................7
3. Security Considerations...........................................8
4. IANA Considerations...............................................9
4.1. New ERO subobject types...................................9
4.2. New RSVP error sub-codes..................................9
5. Acknowledgments..................................................10
6. References.......................................................10
6.1. Normative References.....................................10
6.2. Informative References...................................10
1. Introduction
There are scenarios that require two or more Label Switched
Paths (LSPs) to follow same route in the network. E.g., many
deployments require member LSPs of a bundle/ aggregated link (or
Forwarding Adjacency (FA))) follow the same route. Possible
reasons for two or more LSPs to follow the same end-to-end or
partial route include, but are not limited to:
Ali, Swallow, Filsfils, et al Expires January 2014 [Page 2]
Internet-Draft draft-ali-ccamp-rsvp-te-include-route-04.txt
. Fate sharing: an application may require that two or more LSP
fail together. In the example of bundle link this would mean
that if one component goes down, the entire bundle goes down.
. Homogeneous Attributes: it is often required that two or more
LSPs have the same TE metrics like latency, delay variation,
etc. In the example of a bundle/ aggregated link this would
meet the requirement that all component links (FAs) of a
bundle should have same latency and delay variation. As noted
in [OSPF-TE-METRIC] and [ISIS-TE-METRIC], in certain
networks, such as financial information networks, network
performance (e.g. latency and latency variation) is becoming
critical and hence having bundles with component links (FAs)
with homogeneous delay and delay variation is important.
Similarly, there are scenarios where two or more LSPs need to
follow a given resource in the network, e.g., two partially
overlapping LSPs are required. In this case, inclusion of
certain abstract nodes or resources between a specific pair of
abstract nodes present in an ERO is required.
The RSVP-TE specification [RFC3209] and GMPLS extensions to
RSVP-TE [RFC3473] allow abstract nodes and resources to be
explicitly included in a path setup, e.g., using IPv4 prefix ERO
subobject [RFC3209], IPv6 prefix ERO subobject [RFC3209] and
Unnumbered Interface ID ERO subobject [RFC3477], etc. However,
such inclusion may not be possible in the following scenarios:
. Inclusion of a LSP path which does not originate, terminate
or traverse the source node, in which case the addresses of
the path for which inclusion is required are unknown to the
source node.
. Inclusion of a LSP path which, while known at the source node
of the diverse LSP, has incomplete or unavailable route
information, e.g. due to confidentiality of the path
attributes. In these cases, the ingress node lacks sufficient
knowledge about the loose hop. The ingress node, therefore,
is not able to divide a loose hop into a proper sequence of
strict or a sequence of finer-grained loose hops. Inter-
domain and GMPLS overlay networks may present such
restrictions.
The above-mentioned use cases require relevant path inclusion
requirements to be communicated to the route expanding nodes.
This document addresses these requirements and defines
procedures to address them.
Ali, Swallow, Filsfils, et al Expires January 2014 [Page 3]
Internet-Draft draft-ali-ccamp-rsvp-te-include-route-04.txt
2. RSVP-TE signaling extensions
New IPv4 and IPv6 Point-to-Point (P2P) LSP ERO subobject types
are defined in this document. These ERO subobjects are used to
communicate path inclusion requirements to the ERO expanding
node(s). For this purpose, the subobjects carry RSVP-TE
Forwarding Equivalence Class (FEC) of the reference LSP who's
Path is be used to expand the loose hop of the LSP being
signaled. This document only defines the use of these objects
for ERO loose hops.
2.1. IPv4 Point-to-Point LSP ERO subobject
The IPv4 Point-to-Point LSP ERO subobject is defined 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 |Inclusion Flags| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel end point address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved (MUST be zero) | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel sender address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved (MUST be zero) | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L
The L bit is an attribute of the subobject. The L bit is
set if the subobject represents a loose hop in the ERO.
If the bit is not set, the subobject represents a strict
hop in the explicit route.
This document only defines the use of the subobject in
loose hopes in the ERO, i.e., L bit MUST of set to 1.
Type
IPv4 Point-to-Point LSP subobject
(to be assigned by IANA; suggested value: 38).
Ali, Swallow, Filsfils, et al Expires January 2014 [Page 4]
Internet-Draft draft-ali-ccamp-rsvp-te-include-route-04.txt
Length
The length contains the total length of the subobject in
bytes, including the type and length fields. The length is
always 24.
Inclusion Flags
The Inclusion-Flags are used to communicate desirable
types of inclusion. The following flags are defined.
0x01 = Mandatory inclusion
This flag is used to indicate that the route of the LSP
being signaled MUST follow the path specified by the LSP
subobject.
0x02 = Best-effort inclusion
This flag is used to indicate that the route of the LSP
being signaled SHOULD follow the path specified by the
LSP subobject.
The remaining fields are used to specify RSVP-TE FEC of the
reference LSP who's Path is be used to expand the route of the
LSP being signaled. Specifically,
Tunnel ID
Tunnel ID of the reference LSP who's Path is be used to
expand the route of the LSP being signaled.
Extended Tunnel ID
Extended Tunnel ID of the reference LSP who's Path is be
used to expand the route of the LSP being signaled.
IPv4 tunnel sender address
IPv4 tunnel sender address of the reference LSP who's
path is be used to expand the route of the LSP being
signaled.
LSP ID
Ali, Swallow, Filsfils, et al Expires January 2014 [Page 5]
Internet-Draft draft-ali-ccamp-rsvp-te-include-route-04.txt
LSP ID of the reference LSP who's Path is be used to
expand the route of the LSP being signaled.
2.2. IPv6 Point-to-Point LSP ERO subobject
The IPv6 Point-to-Point LSP ERO subobject is defined 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 |Inclusion Flags| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel sender address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel sender address (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel sender address (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel sender address (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved (MUST be zero) | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L
The L bit is an attribute of the subobject. The L bit is
set if the subobject represents a loose hop in the ERO.
Ali, Swallow, Filsfils, et al Expires January 2014 [Page 6]
Internet-Draft draft-ali-ccamp-rsvp-te-include-route-04.txt
If the bit is not set, the subobject represents a strict
hop in the explicit route.
This document only defines the use of the subobject in
loose hopes in the ERO, i.e., L bit MUST of set to 1.
Type
IPv6 Point-to-Point LSP subobject
(to be assigned by IANA; suggested value: 39).
Length
The length contains the total length of the subobject in
bytes, including the type and length fields. The length is
always 48.
Inclusion Flags
The Inclusion Flags are as defined for the IPv4 Point-to-
Point LSP XRO subobject.
The remaining fields are used to specific RSVP-TE FEC of the
reference LSP who's Path is be used to expand the route of the
LSP being signaled.
2.3. Processing rules for LSP ERO subobjects
The basic processing rules of an ERO are not altered. Please
refer to [RFC3209] for details.
If an LSR strips all local subobjects from an ERO carried in a
Path message (according to the procedures in [RFC3209]) and
finds that the next subobject is an IPv4 P2P LSP subobject or
IPv6 P2P LSP subject, it MUST attempt to resolve the LSP
subobject as described in the following.
If the L bit of the LSP subobject is not set, i.e., the
subobject represents a strict hop in the explicit route, the
processing node MUST respond with a PathErr message with the
error code "Routing Problem" (24) and the error value "Bad
initial subobject" (4).
Ali, Swallow, Filsfils, et al Expires January 2014 [Page 7]
Internet-Draft draft-ali-ccamp-rsvp-te-include-route-04.txt
If the inclusion flags of the LSP subobject is set to "mandatory
inclusion", the processing node follows the following procedure:
- If the path taken by the LSP referenced in the LSP subobject
is known to the processing node and the path contains the
loose abstract node in the ERO hop, the processing node MUST
ensure that loose hop expansion to the next abstract node
follows the referenced path.
- If the path taken by the LSP referenced in the LSP subobject
is unknown to the processing node or the referenced path does
not contain the loose abstract node in the ERO hop, the
processing node MUST sent a PathErr message with the error
code "Routing Problem" (24) and the new error value "unknown
or inconsistent LSP suboject" (value to be assigned by IANA)
for the signaled LSP.
If the inclusion flags of the LSP subobject is set to "best-
effort inclusion", the processing node follows the following
procedure:
- If the path taken by the LSP referenced in the LSP subobject
is known to the processing node and the path contains the
loose abstract node in the ERO hop, the processing node
SHOULD ensure that loose hop expansion to the next abstract
node follows the referenced path.
- If the path taken by the LSP referenced in the LSP subobject
is unknown to the processing node and/ or the referenced path
does not contain the loose abstract node in the ERO hop, the
processing node SHOULD ignore the route inclusion specified
in the LSP subobject and SHOULD compute a suitable path to
the loose abstract node in the ERO hop and 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 " unknown
or inconsistent LSP suboject" (value to be assigned by IANA)
for the signaled LSP.
3. Security Considerations
This document does not introduce any additional security issues
above those identified in [RFC5920], [RFC2205], [RFC3209], and
[RFC3473] and [RFC4874].
Ali, Swallow, Filsfils, et al Expires January 2014 [Page 8]
Internet-Draft draft-ali-ccamp-rsvp-te-include-route-04.txt
4. IANA Considerations
4.1. New ERO subobject types
This document adds the following new subobject of the existing
entry for ERO (20, EXPLICIT_ROUTE):
Value Description
----- ------------
TBA IPv4 Point-to-Point LSP ERO subobject
TBA IPv6 Point-to-Point LSP ERO subobject
These subobject may be present in the Explicit Route Object, but
not in the Route Record Object.
4.2. New RSVP error sub-codes
IANA registry: RSVP PARAMETERS
Subsection: Error Codes and Globally-Defined Error Value Sub-
Codes
For Error Code "Routing Problem" (24) (see [RFC3209]) the
following sub-codes are defined.
Sub-code Value
-------- -----
Unknown or inconsistent LSP suboject To be assigned by
IANA.
For Error Code "Notify Error" (25) (see [RFC3209]) the following
sub-codes are defined.
Sub-code Value
-------- -----
Unknown or inconsistent LSP suboject To be assigned by
IANA.
Ali, Swallow, Filsfils, et al Expires January 2014 [Page 9]
Internet-Draft draft-ali-ccamp-rsvp-te-include-route-04.txt
5. Acknowledgments
Authors would like to thank Gabriele Maria Galimberti, Luyuan
Fang and Walid Wakim for their review comments.
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
V., and G. Swallow, "RSVP-TE: Extensions to RSVP for
LSP Tunnels", RFC 3209, December 2001.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions",
RFC 3473, January 2003.
6.2. Informative References
[RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter,
"Generalized Multiprotocol Label Switching (GMPLS)
User-Network Interface (UNI): Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Support for the
Overlay Model", RFC 4208, October 2005.
[RFC6001] Papadimitriou, D., Vigoureux, M., Shiomoto, K.,
Brungard, D., and JL. Le Roux, "Generalized MPLS
(GMPLS) Protocol Extensions for Multi-Layer and Multi-
Region Networks (MLN/MRN)", RFC 6001, October 2010.
[RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered
Links in Resource ReSerVation Protocol - Traffic
Engineering (RSVP-TE)", RFC 3477, January 2003.
[RFC2209] Braden, R. and L. Zhang, "Resource ReSerVation
Protocol (RSVP) -- Version 1 Message Processing
Rules", RFC 2209, September 1997.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010.
Authors' Addresses
Ali, Swallow, Filsfils, et al Expires January 2014 [Page 10]
Internet-Draft draft-ali-ccamp-rsvp-te-include-route-04.txt
Zafar Ali
Cisco Systems, Inc.
Email: zali@cisco.com
George Swallow
Cisco Systems, Inc.
swallow@cisco.com
Clarence Filsfils
Cisco Systems, Inc.
cfilsfil@cisco.com
Matt Hartley
Cisco Systems
Email: mhartley@cisco.com
Ori Gerstel
Cisco Systems
ogerstel@cisco.com
Kenji Kumaki
KDDI Corporation
Email: ke-kumaki@kddi.com
Rudiger Kunze
Deutsche Telekom AG
Ruediger.Kunze@telekom.de
Ali, Swallow, Filsfils, et al Expires January 2014 [Page 11]