Internet DRAFT - draft-hartley-ccamp-rro-editing
draft-hartley-ccamp-rro-editing
CCAMP Working Group Matt Hartley
Internet Draft Zafar Ali
Intended status: Standards Track Cisco Systems
Expires: August 13, 2014 O. Gonzalez de Dios
Telefonica Global CTO
C. Margaria
Coriant R&D GmbH
Xian Zhang
Huawei
February 14, 2014
RSVP-TE Extensions for RRO Editing
draft-hartley-ccamp-rro-editing-01.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 August 13, 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
Hartley, Ali, Swallow Expires August 14, 2014 [Page 1]
Internet-Draft draft-hartley-ccamp-rro-editing-01 February 2014
Provisions and are provided without warranty as described in the
Simplified BSD License.
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 Multi-domain Networks....................3
1.1.2. RRO Reduction........................................3
2. RSVP-TE Signaling Extensions...................................3
2.1. RRO-edit LSP_ATTRIBUTES TLV...............................3
2.2. RRO-edit TLV Processing Rules.............................5
3. Security Considerations........................................6
4. IANA Considerations............................................6
4.1. LSP_ATTRIBUTES Object.....................................6
5. Acknowledgments................................................7
6. References.....................................................7
6.1. Normative References......................................7
6.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 about the path traversed by the LSP
([RFC-3209], [RFC-3473], [RFC-4873], [RFC-5420], [RFC-5553], [DRAFT-
SRLG], [DRAFT-METRIC]). There are cases, described in this document,
in which one or more nodes on the path of an LSP may require that
the data contained in the RRO in the Path and/or Resv be removed or
Hartley, Ali, Swallow, et al Expires August 14, 2014 [Page 2]
Internet-Draft draft-hartley-ccamp-rro-editing-01 February 2014
summarized. However, it is important for the ingress or egress nodes
to know which RRO subobjects have been edited by intermediate nodes.
This document addresses this requirement.
1.1. Use Cases
1.1.1. Overlay and Multi-domain Networks
In the GMPLS overlay model there is a client-server relationship
[RFC4208]. The GMPLS User-Network Interface (UNI) is the reference
point where policies may be applied. In this case, 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 is too large
to fit in the Path or Resv message. In this case a node may
summarize or remove information from the RRO to reduce its size,
rather than dropping it entirely as specified by [RFC-3209].
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 LSP_ATTRIBUTES TLV that can be used to
reference what information in RRO has been edited.
2.1. RRO-edit LSP_ATTRIBUTES TLV
A new LSP_ATTRIBUTES TLV is defined in order to indicate that RRO
sub-object(s) of a specified type have been edited.
Hartley, Ali, Swallow, et al Expires August 14, 2014 [Page 3]
Internet-Draft draft-hartley-ccamp-rro-editing-01 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Edited type | Flags | Edited type | Flags //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Edited type | Flags | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The sub-object fields are defined as follows:
Type (2 bytes): The sub-object type, to be assigned by IANA
(suggested value: 3).
Length (2 bytes): the total length of the TLV, in bytes. It MUST be
a multiple of 4, and at least 8.
The following fields are repeated for each edited type:
Edited type (1 byte): the type of the RRO sub-object to which the
immediately following flags in this sub-object apply.
Flags (1 byte): the flags that apply to the preceding Edited Type,
numbered from 0 as the most significant bit in the field. Three
flags are defined by this document:
. Bit position 0: P (Partial) bit. When set, this bit indicates
that the data contained in RRO sub-objects of the immediately
preceding type is incomplete. This may be because some
information was withheld by a node (i.e. never placed into
the RRO) or because information provided by one node has been
removed by another.
. Bit position 1: S (Summary) bit. When set, this bit indicates
that the data contained in the specified RRO sub-object has
been summarized.
Hartley, Ali, Swallow, et al Expires August 14, 2014 [Page 4]
Internet-Draft draft-hartley-ccamp-rro-editing-01 February 2014
. Bit position 2: R (Removed) bit. When set, this bit indicates
that the specified RRO sub-object has been removed entirely.
The remaining bits of the Flags field are undefined. They MUST be
set to 0 on transmission and MUST be ignored when received.
Padding: This field is present only if an odd number of edited
type/flags pairs is present in the TLV. It is used to ensure the TLV
length is always a multiple of 4 bytes.
2.2. RRO-edit TLV Processing Rules
The processing rules in this section apply to the processing of both
Path and Resv RROs.
The RRO-edit TLV provides information on the changes made to RRO
sub-objects. It MAY be present in the LSP_ATTRIBUTES object in a
Path or Resv message. It MUST NOT be added to the
LSP_REQUIRED_ATTRIBUTES object.
The LSP_ATTRIBUTES object SHOULD contain no more than one RRO-edit
TLV. If a received LSP_ATTRIBUTES object contains multiple RRO-edit
TLVs, the second and subsequent RRO-edit TLVs MUST be ignored.
The RRO-edit TLVs contains pairs of RRO subobject types and flags
relating to that type. Any RRO subobject type MAY be present in the
RRO-edit TLV. Each RRO subobject type SHOULD appear only once; if a
RRO subobject type occurs more than once then only the first
occurrence is meaningful, and subsequent occurrences MUST be
ignored.
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 and no further processing is required.
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
incomplete or summarized data on its own behalf, then the following
rules apply at the processing node.
. The node MAY choose not to add or amend the RRO-edit TLV if its
local policy prevents this.
. For each RRO subobject type that the processing node has
edited, a RRO-edit type/flags pair SHOULD be added to the RRO-
edit TLV if it does not already exist. If a RRO-edit type/flags
Hartley, Ali, Swallow, et al Expires August 14, 2014 [Page 5]
Internet-Draft draft-hartley-ccamp-rro-editing-01 February 2014
pair for the edited subobject type is already present in the
RRO-edit TLV, the node SHOULD set additional flags in that
subobject if appropriate.
. The node SHOULD set the appropriate P/S/R bits for the RRO
subobject in the RRO-edit TLV to indicate the changes that have
been made to RRO subobjects of that type.
. A node SHOULD NOT insert a RRO-edit type/flags pair with all
flags set to zero.
. A node SHOULD NOT unset any P/S/R bit that is set in a received
RRO-edit TLV.
. A node SHOULD NOT remove any RRO-edit type/flags pair from the
RRO-edit TLV.
. A RRO-edit TLV with no RRO-edit type/flags pairs (i.e. one of
length 4) is considered invalid. It MUST be ignored on receipt
and MUST NOT be added to a LSP_ATTRIBUTES object.
. Unassigned flag bits are considered reserved. They MUST be set
to zero.
. The RRO-edit TLV length MUST be a multiple of 4. If an odd
number of RRO-subobject/flags pairs is present on transmission,
a 16-bit Padding field MUST be added to the TLV. If an even
number of RRO-subobject/flags pairs is present on transmission,
the Padding MUST NOT be added. If present, the Padding bytes
MUST be set to zero on transmission and MUST be ignored on
receipt.
. Any set flag whose meaning is either unassigned or not
understood SHOULD be ignored, and MUST be included unchanged in
the transmitted RRO-edit TLV.
. A RRO-edit type/flags pair with an unknown RRO subobject type
SHOULD be ignored and MUST passed unchanged in the transmitted
RRO-edit TLV.
3. Security Considerations
There are no new security considerations introduced by this
document.
4. IANA Considerations
4.1. LSP_ATTRIBUTES Object
IANA has made the following assignments in the "Attributes TLV Space"
section of the "RSVP-TE PARAMETERS" registry located at
http://www.iana.org/assignments/rsvp-te-parameters/rsvp-te-
parameters.xml.
This document introduces a new LSP_ATTRIBUTES sub-object:
Hartley, Ali, Swallow, et al Expires August 14, 2014 [Page 6]
Internet-Draft draft-hartley-ccamp-rro-editing-01 February 2014
Type Name Reference
------------------------ ------------ ---------
TBD (suggested value: 3) RRO-edited TLV This I-D
This TLV is allowed on LSP_ATTRIBUTES, and not allowed on
LSP_REQUIRED_ATTRIBUTES.
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.
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.
[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.
6.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.
[RFC5553] Farrel, A., Ed., Bradford, R., Vasseur, JP., "Resource
Reservation Protocol (RSVP) Extensions for Path Key
Support", RFC 5553, May 2009.
Hartley, Ali, Swallow, et al Expires August 14, 2014 [Page 7]
Internet-Draft draft-hartley-ccamp-rro-editing-01 February 2014
[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.
Author's Addresses
Matt Hartley
Cisco Systems
Email: mhartley@cisco.com
Zafar Ali
Cisco Systems
Email: zali@cisco.com
Oscar Gonzalez de Dios
Telefonica Global CTO
Email: ogondio@tid.es
Cyril Margaria
Coriant R&D GmBH
Email: cyril.margaria@gmail.com
Xian Zhang
Huawei Technologies
Email: zhang.xian@huawei.com
Disclaimer of Validity
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE IETF TRUST, THE INTERNET
SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Hartley, Ali, Swallow, et al Expires August 14, 2014 [Page 8]
