CCAMP Working Group Matt Hartley
Internet Draft Zafar Ali
Intended status: Standards Track Cisco Systems
Expires: April 20, 2014 O. Gonzalez de Dios
Telefonica I+D
C. Margaria
Coriant R&D GmbH
October 21, 2013
RSVP-TE extensions for RRO editing
draft-hartley-ccamp-rro-editing-00.txt
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 April 20, 2014.
Copyright Notice
Copyright (c) 2013 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.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November 10,
2008. The person(s) controlling the copyright in some of this material
may not have granted the IETF Trust the right to allow modifications of
such material outside the IETF Standards Process. Without obtaining an
adequate license from the person(s) controlling the copyright in such
materials, this document may not be modified outside the IETF Standards
Process, and derivative works of it may not be created outside the IETF
Standards Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Hartley, Ali, at al Expires April 21, 2014 [Page 1]
Internet-Draft draft-hartley-ccamp-rro-editing-00 October 2013
Abstract
This document provides extensions for the Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) to allow the communication of
changes made by a node to the information provided by other nodes in
a ROUTE_RECORD Object (RRO) in Path and Resv messages, or to
indicate that it has itself provided incomplete information.
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].
Table of Contents
1. Introduction...................................................2
1.1. Use Cases.................................................3
1.1.1. Overlay and inter-domain networks....................3
1.1.2. RRO reduction........................................3
2. RSVP-TE signaling extensions...................................3
2.1. IPv4 RRO-edit RRO sub-object..............................3
2.2. IPv6 RRO-edit RRO sub-object..............................4
2.3. RRO-edit sub-object Processing Rules......................4
3. Security Considerations........................................5
4. IANA Considerations............................................5
4.1. ROUTE_RECORD Object.......................................5
5. Acknowledgments................................................6
5.1. Normative References......................................7
5.2. Informative References....................................7
Author's Addresses................................................8
Disclaimer of Validity............................................8
1. Introduction
The signaling process of a Label-Switched Path (LSP) may require
gathering information of the actual path traversed by the LSP. The
procedure for collecting this information includes the hop-by-hop
construction of a Record Route Object (RRO) in the Path and Resv
messages, containing information on the path traversed by the LSP
([RFC-3209], [RFC-3473], [RFC-4873], [RFC-5420], [RFC-5553], [DRAFT-
SRLG], [DRAFT-METRIC]). There are several use cases, described in
this document, in which one or more nodes on the path of an LSP may
require that the RRO in the Path and/or Resv be edited to remove or
summarize data contained in the RRO. However, it is important for
the ingress or egress nodes to know what RRO subobjects have been
edited by intermediate nodes. This document addresses this
requirement.
Hartley, Ali, et al Expires April 21, 2014 [Page 2]
Internet-Draft draft-hartley-ccamp-rro-editing-00 October 2013
1.1. Use Cases
Use cases where RRO editing can take place are described in this
subsection.
1.1.1. Overlay and inter-domain networks
In the GMPLS overlay model there is a client-server relationship
[RFC4208]. GMPLS User-Network Interface (UNI) is the reference point
where policies can be applied. In this cases policy at the server
network boundary may require that some or all information related to
the server network be edited, summarized or removed when
communicating with the client nodes. Similar policy requirements
exist for inter-domain LSPs and in E-NNI use case.
1.1.2. RRO reduction
If an LSP with many hops is signaled and a great deal of information
is collected at each hop, it is possible that the RRO may grow to
the point where it reaches its maximum possible size or RSVP packet
fragmentation becomes a problem. In this case a node may summarize
or remove information from the RRO to reduce its size.
2. RSVP-TE signaling extensions
This section describes the signaling extensions required to address
the aforementioned requirements. Specifically, the requirements are
addressed by defining a new RRO sub-object that can be used to
reference what information in RRO has been edited, as detailed in
the following.
2.1. IPv4 RRO-edit RRO sub-object
A new RRO sub-object is defined in order to indicate that another
RRO sub-object within the same hop has been edited.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Edited type |E|P|S|R|reserve|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Editing node address (4 bytes) |
Hartley, Ali, et al Expires April 21, 2014 [Page 3]
Internet-Draft draft-hartley-ccamp-rro-editing-00 October 2013
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The sub-object fields are defined as follows:
Type: The sub-object type, to be assigned by IANA (suggested value:
TBD).
Length: the total length of the TLV, in bytes. It MUST be 8.
Edited type: the type of the sub-object within the same hop to which
the flags in this sub-object apply.
E (Edited) bit: When set, this bit indicates that the specified RRO
sub-object has been edited in some way.
P (Partial) bit: When set, this bit indicates that the data
contained in the specified RRO sub-object is incomplete.
S (Summary) bit: When set, this bit indicates that the data
contained in the specified RRO sub-object has been summarized.
R (Removed) bit. When set, this bit indicates that the specified RRO
sub-object has been removed entirely.
Reserved: This field SHOULD be set to zero on transmission, and MUST
be ignored on receipt.
Editing node address: an IPv4 address unique to the node that has
edited the RRO and inserted this sub-object.
2.2. IPv6 RRO-edit RRO sub-object
To be added in future revision.
2.3. RRO-edit sub-object Processing Rules
The processing rules in this section apply to the processing of both
Path and Resv RROs.
Normal RRO processing involves a node simply adding data related to
the local hop to the RRO received from the prior node to RRO, and
placing the new RRO in the message to be transmitted. In this case
the transmitted RRO contains all data that was present in the
received RRO.
If a node edits the data in the received RRO such that the same data
is not present in the transmitted RRO, or if it is supplying
Hartley, Ali, et al Expires April 21, 2014 [Page 4]
Internet-Draft draft-hartley-ccamp-rro-editing-00 October 2013
incomplete or summarized data on its own behalf, then the following
rules apply at the processing node.
. For each sub-object type that has been edited within a hop, a
RRO-edited sub-object SHOULD be inserted into the same hop in
the RRO. The RRO-edited sub-object MAY be omitted entirely if
the processing node's policy prevents communication of this
information.
. Multiple RRO-edited sub-objects describing edits to the same
type of sub-object (i.e. with the same "Edited type" field)
SHOULD NOT be added in the same hop.
. Multiple RRO-edited sub-objects describing edits to the same
type of sub-object (i.e. with the same "Edited type" field) MAY
be added to different hops if appropriate.
. The node SHOULD add its own local address to the "editing node
address" field of the RRO-edited sub-object. This field MAY be
set to zero if the processing node's policy prevents self-
identification.
. The node SHOULD set the appropriate bits in the flags field to
indicate the changes that have been made to the subsequent RRO
sub-object.
. A node SHOULD NOT insert a RRO-edited sub-object with all flags
set to zero.
. Unassigned flag bits are considered reserved. They SHOULD be
set to zero.
The following rules apply at a node processing a received RRO-edited
sub-object:
. Any set flag whose meaning is either unassigned or not
understood SHOULD be ignored.
. If an RRO is received with multiple RRO-edited sub-objects
describing edits to the same type of sub-object within the same
hop, the second and subsequent RRO-edited sub-objects SHOULD be
ignored.
3. Security Considerations
To be added in a future version.
4. IANA Considerations
4.1. ROUTE_RECORD Object
IANA has made the following assignments in the "Class Names, Class
Numbers, and Class Types" section of the "RSVP PARAMETERS" registry
located at http://www.iana.org/assignments/rsvp-parameters. It is
Hartley, Ali, et al Expires April 21, 2014 [Page 5]
Internet-Draft draft-hartley-ccamp-rro-editing-00 October 2013
requested that IANA make assignments from the ROUTE_RECORD RFC 3209
[RFC3209] portions of this registry.
This document introduces a new RRO sub-object:
Type Name Reference
--------- ---------------------- ---------
TBD RRO-edited sub-object This I-D
5. Acknowledgments
The authors would like to thank Lou Berger for suggesting the core
idea described in this draft. The authors would also like to thank
George Swallow for his input.
Hartley, Ali, et al Expires April 21, 2014 [Page 6]
Internet-Draft draft-hartley-ccamp-rro-editing-00 October 2013
References
5.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.
5.2. Informative References
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel,
"GMPLS Segment Recovery", RFC 4873, May 2007.
[RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A.
Ayyangarps, "Encoding of Attributes for MPLS LSP
Establishment Using Resource Reservation Protocol Traffic
Engineering (RSVP-TE)", RFC 5420, February 2009.
[RFC5553] Farrel, A., Ed., Bradford, R., Vasseur, JP., "Resource
Reservation Protocol (RSVP) Extensions for Path Key
Support", RFC 5553, May 2009.
[DRAFT-SRLG] Zhang, F., Li, D., Gonzalez de Dios, O., Margaria, C.,
Hartley, M., "RSVP-TE Extensions for Collecting SRLG
Information", draft-ietf-ccamp-rsvp-te-srlg-collect-03,
October 2013.
[DRAFT-METRIC] Ali, Z., Swallow, G., Filsfils, C., Hartley, M.,
Kumaki, K., Kunze, R., "Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE) extension for recording TE
Metric of a Label Switched Path", draft-ietf-ccamp-te-
metric-recording-02, July 2013.
Hartley, Ali, et al Expires April 21, 2014 [Page 7]
Internet-Draft draft-hartley-ccamp-rro-editing-00 October 2013
Author's Addresses
Matt Hartley
Cisco Systems
Email: mhartley@cisco.com
Zafar Ali
Cisco Systems
Email: zali@cisco.com
Oscar Gonzalez de Dios
Telefonica I+D
Email: ogondio@tid.es
Cyril Margaria
Email: cyril.margaria@gmail.com
Hartley, Ali, et al Expires April 21, 2014 [Page 8]