doc: Add RFC documents

1 files changed, 843 insertions, 0 deletions

diff --git a/doc/rfc/rfc7570.txt b/doc/rfc/rfc7570.txt
new file mode 100644
index 0000000..5c5e918
--- /dev/null
+++ b/doc/rfc/rfc7570.txt
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                  C. Margaria, Ed.
+Request for Comments: 7570                                       Juniper
+Category: Standards Track                                  G. Martinelli
+ISSN: 2070-1721                                                    Cisco
+                                                                S. Balls
+                                                               B. Wright
+                                                              Metaswitch
+                                                               July 2015
+
+
+ Label Switched Path (LSP) Attribute in the Explicit Route Object (ERO)
+
+Abstract
+
+   RFC 5420 extends RSVP-TE to specify or record generic attributes that
+   apply to the whole of the path of a Label Switched Path (LSP).  This
+   document defines an extension to the RSVP Explicit Route Object (ERO)
+   and Record Route Object (RRO) to allow them to specify or record
+   generic attributes that apply to a given hop.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7570.
+
+Copyright Notice
+
+   Copyright (c) 2015 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.
+
+
+
+Margaria, et al.             Standards Track                    [Page 1]
+
+RFC 7570               General ERO LSP Parameters              July 2015
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
+     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
+   2.  ERO Hop Attributes Subobject  . . . . . . . . . . . . . . . .   3
+     2.1.  Encoding  . . . . . . . . . . . . . . . . . . . . . . . .   3
+     2.2.  Hop Attributes TLVs . . . . . . . . . . . . . . . . . . .   4
+     2.3.  Procedures  . . . . . . . . . . . . . . . . . . . . . . .   4
+   3.  RRO Hop Attributes Subobject  . . . . . . . . . . . . . . . .   6
+     3.1.  Encoding  . . . . . . . . . . . . . . . . . . . . . . . .   6
+     3.2.  Procedures  . . . . . . . . . . . . . . . . . . . . . . .   6
+       3.2.1.  Subobject Presence Rule . . . . . . . . . . . . . . .   6
+       3.2.2.  Reporting Compliance with ERO Hop Attributes  . . . .   7
+       3.2.3.  Compatibility with RRO Attributes Subobject . . . . .   7
+   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
+     4.1.  ERO Hop Attributes Subobject  . . . . . . . . . . . . . .   8
+     4.2.  RRO Hop Attributes Subobject  . . . . . . . . . . . . . .   8
+     4.3.  Existing Attribute Flags  . . . . . . . . . . . . . . . .   8
+     4.4.  Existing LSP Attribute TLVs . . . . . . . . . . . . . . .  10
+   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
+   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
+     6.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
+     6.2.  Informative References  . . . . . . . . . . . . . . . . .  13
+   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  14
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15
+
+1.  Introduction
+
+   Generalized MPLS (GMPLS) Traffic Engineering (TE) Label Switched
+   Paths (LSPs) can be route constrained by making use of the Explicit
+   Route Object (ERO) and related subobjects as defined in [RFC3209],
+   [RFC3473], [RFC3477], [RFC4873], [RFC4874], [RFC5520], and [RFC5553].
+   Several documents have identified the need for attributes that can be
+   targeted at specific hops in the path of an LSP, including [RFC6163],
+   [WSON-SIG], [RFC7571], or [OBJ-FUN].  This document provides a
+   generic mechanism for use by these other documents.
+
+   RSVP already supports generic extension of LSP attributes in
+   [RFC5420].  In order to support current and future ERO constraint
+   extensions, this document provides a mechanism to define per-hop
+   attributes.
+
+   The document describes a generic mechanism for carrying information
+   related to specific nodes when signaling an LSP.  This document does
+   not restrict what that information can be used for.  The defined
+   approach builds on LSP attributes defined in [RFC5420] and enables
+
+
+
+
+
+Margaria, et al.             Standards Track                    [Page 2]
+
+RFC 7570               General ERO LSP Parameters              July 2015
+
+
+   attributes to be expressed in ERO and Secondary Explicit Route
+   Objects (SEROs).  A new ERO subobject is defined, containing a list
+   of generic per-hop attributes.
+
+1.1.  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 RFC 2119 [RFC2119].
+
+2.  ERO Hop Attributes Subobject
+
+   The ERO Hop Attributes subobject is OPTIONAL.  If used, it is carried
+   in the ERO or SERO.  The subobject uses the standard format of an ERO
+   subobject.
+
+2.1.  Encoding
+
+   The length is variable and content is a list of Hop Attributes TLVs
+   defined in Section 2.2.  The size of the ERO subobject limits the
+   size of the Hop Attributes TLV to 250 bytes.  The typical size of
+   currently defined and forthcoming LSP_ATTRIBUTE TLVs applicable to a
+   specific hop (WSON_SIGNALING, Objective Function (OF), and Metric) is
+   not foreseen to exceed this limit.
+
+   The ERO Hop Attributes 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    |    Reserved                 |R|
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      //                  Hop Attributes TLVs                        //
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The L, Type, and Length parameters are as defined in [RFC3209],
+   Section 4.3.3.  The L bit MUST be set to 0.  The Type for the ERO Hop
+   Attributes subobject is 35.  The Hop Attributes TLVs are encoded as
+   defined in Section 2.2.
+
+   Reserved:  Reserved MUST be set to 0 when the subobject is inserted
+      in the ERO, MUST NOT be changed when a node processes the ERO, and
+      MUST be ignored on the node addressed by the preceding ERO
+      subobjects.
+
+
+
+
+
+Margaria, et al.             Standards Track                    [Page 3]
+
+RFC 7570               General ERO LSP Parameters              July 2015
+
+
+   R: This bit reflects the LSP_REQUIRED_ATTRIBUTE and LSP_ATTRIBUTE
+      semantic defined in [RFC5420].  When set, it indicates required
+      hop attributes to be processed by the node.  When cleared, it
+      indicates that the hop attributes are not required as described in
+      Section 2.3.
+
+   Hop Attributes TLVs:  The TLVs as defined in Section 2.2.
+
+2.2.  Hop Attributes TLVs
+
+   ERO attributes carried by the new objects defined in this document
+   are encoded within TLVs.  Each object MAY contain one or more TLVs.
+   There are no ordering rules for TLVs, and interpretation SHOULD NOT
+   be placed on the order in which TLVs are received.  The TLV format is
+   defined in [RFC5420], Section 3.
+
+   The Attribute Flags TLV defined in [RFC5420] is carried in an ERO Hop
+   Attributes subobject.  Flags set in the Attribute Flags TLV [RFC5420]
+   carried in an ERO Hop Attributes subobject SHALL be interpreted in
+   the context of the received ERO.  Only a subset of defined flags are
+   defined as valid for use in Attribute Flags TLV carried in an ERO Hop
+   Attributes subobject.  Invalid flags SHALL be silently ignored.
+   Unknown flags SHOULD trigger the generation of a PathErr with Error
+   Code "Unknown Attributes Bit" as defined in [RFC5420], Section 5.2.
+   The set of valid flags are defined in Section 4.3.
+
+   The presence and ordering rule of the Attribute Flags TLV in an ERO
+   Hop Attributes subobject is defined by each Flag.  A document
+   defining a flag to be used in an Attribute Flags TLV carried in the
+   ERO Hop Attributes subobject has to describe:
+
+   o  after which kinds of ERO subobject the flag is valid,
+
+   o  if ordering of the flag and other ERO subobjects associated with
+      the same hop (e.g., Label subobjects) is significant,
+
+   o  if ordering is significant, how the flag is interpreted in
+      association with the preceding subobjects, and
+
+   o  any flag modification rules that might apply.
+
+2.3.  Procedures
+
+   As described in [RFC3209], the ERO is managed as a list of subobjects
+   each identifying a specific entity, an abstract node, or a link that
+   defines a waypoint in the network path.  Identifying subobjects of
+   various types are defined in [RFC3209], [RFC3477], [RFC4873],
+   [RFC4874], [RFC5520], and [RFC5553].
+
+
+
+Margaria, et al.             Standards Track                    [Page 4]
+
+RFC 7570               General ERO LSP Parameters              July 2015
+
+
+   [RFC3473] modified the ERO list by allowing one or two Label
+   subobjects to be interposed in the list after a subobject identifying
+   a link.  One or more ERO Hop Attributes subobjects applicable to a
+   particular hop MAY be inserted directly after any of the existing
+   identifying subobjects defined in[RFC3209], [RFC3477], [RFC4873],
+   [RFC4874], [RFC5520], and [RFC5553].  If any Label subobjects are
+   present for a hop, the ERO Hop Attributes subobject(s) MAY also be
+   inserted after the Label subobjects.
+
+   The attributes specified in an ERO Hop Attributes subobject apply to
+   the immediately preceding subobject(s) in the ERO subobject list.
+
+   A document defining a specific Hop Attributes TLV has to describe:
+
+   o  after which kinds of ERO subobject they are valid,
+
+   o  if ordering of the Hop Attributes subobject and other ERO
+      subobjects associated with the same hop (e.g., Label subobjects)
+      is significant,
+
+   o  if ordering is significant, how the attribute is interpreted in
+      association with the preceding ERO subobjects, and
+
+   o  any TLV modification rules that might apply.
+
+   For instance, subobject presence rules can be defined by describing
+   rules similar to [RFC4990], Section 6.1.
+
+   If a node is processing an ERO Hop Attributes subobject and does not
+   support the handling of the subobject, it will behave as described in
+   [RFC3209] when an unrecognized ERO subobject is encountered.  This
+   node will return a PathErr with Error Code "Routing Error" and Error
+   Value "Bad EXPLICIT_ROUTE object" with the EXPLICIT_ROUTE object
+   included, truncated (on the left) to the offending unrecognized
+   subobject.
+
+   When the R bit is set, a node MUST examine the attributes TLV present
+   in the subobject following the rules described in [RFC5420],
+   Section 5.2.  When the R bit is not set, a node MUST examine the
+   attributes TLV present in the subobject following the rules described
+   in [RFC5420], Section 4.2.
+
+   A node processing an ERO Hop Attributes subobject with a Hop
+   Attributes TLV longer than the ERO subobject SHOULD return a PathErr
+   with Error Code "Routing Error" and Error Value "Bad EXPLICIT_ROUTE
+   object" with the EXPLICIT_ROUTE object included, truncated (on the
+   left) to the offending malformed subobject.  A processing node MUST
+
+
+
+
+Margaria, et al.             Standards Track                    [Page 5]
+
+RFC 7570               General ERO LSP Parameters              July 2015
+
+
+   NOT originate a Hop Attributes TLV longer than the ERO Hop Attributes
+   subobject.  The processing of the Hop Attributes TLVs SHOULD be
+   described in the documents defining them.
+
+3.  RRO Hop Attributes Subobject
+
+   In some cases, it is important to determine if an OPTIONAL hop
+   attribute has been processed by a node.
+
+3.1.  Encoding
+
+   The RRO Hop Attributes subobject is OPTIONAL.  If used, it is carried
+   in the RECORD_ROUTE object.  The subobject uses the standard format
+   of an RRO subobject.
+
+   The RRO Hop Attributes 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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |      Type     |     Length    |    Reserved                   |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      //                  Hop Attributes TLVs                        //
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The Type and Length parameters are as defined in [RFC3209],
+   Section 4.4.1.  The Type for the RRO Hop Attributes subobject is 35.
+   The Hop Attributes TLVs are encoded as defined in Section 2.2.
+
+   Reserved:  Reserved MUST be set to 0 when the subobject is inserted
+      in the RRO, MUST NOT be changed when a node processes the RRO, and
+      MUST be ignored on the node addressed by the preceding RRO
+      subobjects.
+
+   Hop Attributes TLVs:  The processed or additional Hop Attributes
+      TLVs, using the format defined in Section 2.2.
+
+3.2.  Procedures
+
+3.2.1.  Subobject Presence Rule
+
+   The RRO rules defined in [RFC3209] are not changed.  The RRO Hop
+   Attributes subobject MUST be pushed after the RRO Attributes
+   subobject (if present) as defined in [RFC5420].  The RRO Hop
+   Attributes subobject MAY be present between a pair of subobjects
+   identifying the Label Switching Router (LSR) or links.  Unless local
+
+
+
+Margaria, et al.             Standards Track                    [Page 6]
+
+RFC 7570               General ERO LSP Parameters              July 2015
+
+
+   policy applies, all such subobjects SHOULD be forwarded unmodified by
+   transit LSRs.
+
+   It is noted that a node (e.g., a domain edge node) MAY edit the RRO
+   to prune/modify the RRO, including the RRO Hop Attributes subobject
+   before forwarding due to confidentiality policy or other reasons (for
+   instance, RRO size reduction).
+
+3.2.2.  Reporting Compliance with ERO Hop Attributes
+
+   To report that an ERO hop attribute has been considered, or to report
+   an additional attribute, an LSR can add a RRO Hop Attributes
+   subobject with the Hop Attributes TLV, which describes the attribute
+   to be reported.  The requirement to report compliance MUST be
+   specified in the document that defines the usage of a hop attribute.
+
+3.2.3.  Compatibility with RRO Attributes Subobject
+
+   The RRO Hop Attributes subobject extends the capability of the RRO
+   Attributes subobject defined in [RFC5420], Section 7.2 by allowing
+   the node to report the attribute value.  The mechanism defined in
+   this document is compatible with the RRO Attributes subobject using
+   the following procedures.
+
+   For LSP attributes signaled in the LSP_ATTRIBUTES or
+   LSP_REQUIRED_ATTRIBUTES objects, a node SHOULD use the RRO Attributes
+   subobject to report processing of those attributes.
+
+   For LSP attributes signaled in the ERO Hop Attributes subobject and
+   not in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES objects, if a
+   node desires to report the attributes, it SHOULD use the RRO Hop
+   Attributes subobject and SHOULD NOT use the RRO Attributes subobject.
+   Ingress nodes not supporting the RRO Hop Attributes subobject will
+   drop the information, as described in [RFC3209], Section 4.4.5.
+
+   A node can use the RRO Hop Attributes subobject to report an LSP
+   attribute signaled in LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES only
+   if the following conditions are met:
+
+      The attribute and its corresponding flag is allowed on both the
+      LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES and LSP Hop Attributes
+      subobject.
+
+      The reporting of an LSP attribute signaled in LSP_ATTRIBUTES or
+      LSP_REQUIRED_ATTRIBUTES in the RRO Hop Attribute is specified in
+      the document defining that LSP attribute.
+
+
+
+
+
+Margaria, et al.             Standards Track                    [Page 7]
+
+RFC 7570               General ERO LSP Parameters              July 2015
+
+
+4.  IANA Considerations
+
+4.1.  ERO Hop Attributes Subobject
+
+   IANA manages the "Resource Reservation Protocol (RSVP) Parameters"
+   registry located at
+   <http://www.iana.org/assignments/rsvp-parameters>.  Per this
+   document, IANA has made an allocation in the Sub-object type 20
+   EXPLICIT_ROUTE - Type 1 Explicit Route registry.
+
+   This document introduces a new ERO subobject:
+
+             Value  Description       Reference
+             ------ ----------------- ------------------------
+             35     Hop Attributes    This document, Section 2
+
+4.2.  RRO Hop Attributes Subobject
+
+   IANA manages the "Resource Reservation Protocol (RSVP) Parameters"
+   registry located at
+   <http://www.iana.org/assignments/rsvp-parameters>.  Per this
+   document, IANA has made an allocation in the Sub-object type 21
+   ROUTE_RECORD - Type 1 Route Record registry.  This value is the same
+   as that in Section 4.1.
+
+   This document introduces a new RRO subobject:
+
+             Value  Description       Reference
+             ------ ----------------- ------------------------
+             35     Hop Attributes    This document, Section 3
+
+4.3.  Existing Attribute Flags
+
+   IANA manages the "Attribute Flags" registry as part of the "Resource
+   Reservation Protocol-Traffic Engineering (RSVP-TE) Parameters"
+   registry located at
+   <http://www.iana.org/assignments/rsvp-te-parameters>.  A new column
+   in the registry is introduced by this document.  This column
+   indicates if the flag is permitted to be used in an Attribute Flags
+   TLV carried in the ERO Hop Attributes subobject.  The column uses the
+   heading "ERO" and the registry has been updated as follows:
+
+
+
+
+
+
+
+
+
+
+Margaria, et al.             Standards Track                    [Page 8]
+
+RFC 7570               General ERO LSP Parameters              July 2015
+
+
+    Bit Name                 Attribute Attribute RRO ERO Reference
+    No.                      FlagsPath FlagsResv
+    0   End-to-end re-       Yes       No        No  No  [RFC4920]
+        routing                                          [RFC5420]
+                                                         This Document
+    1   Boundary re-routing  Yes       No        No  No  [RFC4920]
+                                                         [RFC5420]
+                                                         This Document
+    2   Segment-based re-    Yes       No        No  No  [RFC4920]
+        routing                                          [RFC5420]
+                                                         This Document
+    3   LSP Integrity        Yes       No        No  No  [RFC4875]
+        Required
+                                                         This Document
+    4   Contiguous LSP       Yes       No        Yes No  [RFC5151]
+                                                         This Document
+    5   LSP stitching        Yes       No        Yes No  [RFC5150]
+        desired
+                                                         This Document
+    6   Pre-Planned LSP Flag Yes       No        No  No  [RFC6001]
+                                                         This Document
+    7   Non-PHP behavior     Yes       No        Yes No  [RFC6511]
+        flag
+                                                         This Document
+    8   OOB mapping flag     Yes       No        Yes No  [RFC6511]
+                                                         This Document
+    9   Entropy Label        Yes       Yes       No  No  [RFC6790]
+        Capability
+                                                         This Document
+    10  OAM MEP entities     Yes       Yes       Yes No  [RFC7260]
+        desired
+                                                         This Document
+    11  OAM MIP entities     Yes       Yes       Yes No  [RFC7260]
+        desired
+                                                         This Document
+    12  SRLG collection Flag Yes       Yes       Yes No  [SRLG-COLLECT]
+        (TEMPORARY -                                     This Document
+        registered
+        2014-09-11, expires
+        2015-09-11)
+
+   New allocation requests to this registry SHALL indicate the value to
+   be used in the ERO column.
+
+
+
+
+
+
+
+
+Margaria, et al.             Standards Track                    [Page 9]
+
+RFC 7570               General ERO LSP Parameters              July 2015
+
+
+4.4.  Existing LSP Attribute TLVs
+
+   IANA manages the "Resource Reservation Protocol-Traffic Engineering
+   (RSVP-TE) Parameters" registry located at
+   <http://www.iana.org/assignments/rsvp-te-parameters>.  The
+   "Attributes TLV Space" registry manages the following attributes, as
+   defined in [RFC5420]:
+
+   o  TLV Type (T-field value)
+
+   o  TLV Name
+
+   o  Whether allowed on LSP_ATTRIBUTES object
+
+   o  Whether allowed on LSP_REQUIRED_ATTRIBUTES object
+
+   Per this document, IANA has added the following information for each
+   TLV in the RSVP TLV type identifier registry.
+
+   o  Whether allowed on LSP Hop Attributes ERO subobject
+
+   The existing registry has been modified for existing TLVs as follows.
+   The following abbreviations are used below:
+
+   LSP_A:  Whether allowed on LSP_ATTRIBUTES object.
+
+   LSP_RA:  Whether allowed on LSP_REQUIRED_ATTRIBUTES object.
+
+   HOP_A:  Whether allowed on LSP Hop Attributes subobject.
+
+         T Name                  LSP_A LSP_RA HOP_A Ref.
+         - --------------------- ----- ------ ----- --------------
+         1 Attribute Flags       Yes   Yes    Yes   [RFC5420]
+                                                    This Document
+         2 Service ID TLV        Yes   No     No    [RFC6060]
+                                                    This Document
+         3 OAM Configuration TLV Yes   Yes    No    [RFC7260]
+                                                    This Document
+
+5.  Security Considerations
+
+   This document adds a new subobject in the EXPLICIT_ROUTE and the
+   ROUTE_RECORD objects carried in RSVP messages used in MPLS and GMPLS
+   signaling.  It builds on mechanisms defined in [RFC3209] and
+   [RFC5420] and does not introduce any new security.  The existing
+   security considerations described in [RFC2205], [RFC3209], [RFC3473],
+   and [RFC5420] do apply.
+
+
+
+
+Margaria, et al.             Standards Track                   [Page 10]
+
+RFC 7570               General ERO LSP Parameters              July 2015
+
+
+   As with any RSVP-TE signaling request, the procedures defined in this
+   document permit the transfer and reporting of functional preferences
+   on a specific node.  The mechanism added in this document does allow
+   more control of LSP attributes at a given node.  A node SHOULD check
+   the hop attributes against its policies and admission procedures as
+   it does with other inputs.  A node MAY reject the message using
+   existing RSVP Error Codes like "Policy Control Failure" or "Admission
+   Control Failure".  The node MAY also, depending on the specific TLV
+   procedures, modify the requested attribute.  This can reveal
+   information about the LSP request and status to anyone with
+   unauthorized access.  The mechanism described in this document does
+   not contribute to this issue, which can be only resolved by
+   encrypting the content of the whole signaling message.
+
+   In addition, the reporting of attributes using the RRO can reveal
+   details about the node that the operator wishes to remain
+   confidential.  The same strategy and policies that apply to other RRO
+   subobjects also apply to this new mechanism.  It is RECOMMENDED that
+   domain boundary policies take the releasing of RRO hop attributes
+   into consideration.
+
+6.  References
+
+6.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <http://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC2205]  Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
+              Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
+              Functional Specification", RFC 2205, DOI 10.17487/RFC2205,
+              September 1997, <http://www.rfc-editor.org/info/rfc2205>.
+
+   [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
+              and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
+              Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
+              <http://www.rfc-editor.org/info/rfc3209>.
+
+   [RFC3473]  Berger, L., Ed., "Generalized Multi-Protocol Label
+              Switching (GMPLS) Signaling Resource ReserVation Protocol-
+              Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
+              DOI 10.17487/RFC3473, January 2003,
+              <http://www.rfc-editor.org/info/rfc3473>.
+
+
+
+
+
+
+Margaria, et al.             Standards Track                   [Page 11]
+
+RFC 7570               General ERO LSP Parameters              July 2015
+
+
+   [RFC3477]  Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links
+              in Resource ReSerVation Protocol - Traffic Engineering
+              (RSVP-TE)", RFC 3477, DOI 10.17487/RFC3477, January 2003,
+              <http://www.rfc-editor.org/info/rfc3477>.
+
+   [RFC4873]  Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel,
+              "GMPLS Segment Recovery", RFC 4873, DOI 10.17487/RFC4873,
+              May 2007, <http://www.rfc-editor.org/info/rfc4873>.
+
+   [RFC4874]  Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes -
+              Extension to Resource ReserVation Protocol-Traffic
+              Engineering (RSVP-TE)", RFC 4874, DOI 10.17487/RFC4874,
+              April 2007, <http://www.rfc-editor.org/info/rfc4874>.
+
+   [RFC4875]  Aggarwal, R., Ed., Papadimitriou, D., Ed., and S.
+              Yasukawa, Ed., "Extensions to Resource Reservation
+              Protocol - Traffic Engineering (RSVP-TE) for Point-to-
+              Multipoint TE Label Switched Paths (LSPs)", RFC 4875,
+              DOI 10.17487/RFC4875, May 2007,
+              <http://www.rfc-editor.org/info/rfc4875>.
+
+   [RFC4920]  Farrel, A., Ed., Satyanarayana, A., Iwata, A., Fujita, N.,
+              and G. Ash, "Crankback Signaling Extensions for MPLS and
+              GMPLS RSVP-TE", RFC 4920, DOI 10.17487/RFC4920, July 2007,
+              <http://www.rfc-editor.org/info/rfc4920>.
+
+   [RFC5150]  Ayyangar, A., Kompella, K., Vasseur, JP., and A. Farrel,
+              "Label Switched Path Stitching with Generalized
+              Multiprotocol Label Switching Traffic Engineering (GMPLS
+              TE)", RFC 5150, DOI 10.17487/RFC5150, February 2008,
+              <http://www.rfc-editor.org/info/rfc5150>.
+
+   [RFC5151]  Farrel, A., Ed., Ayyangar, A., and JP. Vasseur, "Inter-
+              Domain MPLS and GMPLS Traffic Engineering -- Resource
+              Reservation Protocol-Traffic Engineering (RSVP-TE)
+              Extensions", RFC 5151, DOI 10.17487/RFC5151, February
+              2008, <http://www.rfc-editor.org/info/rfc5151>.
+
+   [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, DOI 10.17487/RFC5420,
+              February 2009, <http://www.rfc-editor.org/info/rfc5420>.
+
+
+
+
+
+
+
+
+Margaria, et al.             Standards Track                   [Page 12]
+
+RFC 7570               General ERO LSP Parameters              July 2015
+
+
+   [RFC5520]  Bradford, R., Ed., Vasseur, JP., and A. Farrel,
+              "Preserving Topology Confidentiality in Inter-Domain Path
+              Computation Using a Path-Key-Based Mechanism", RFC 5520,
+              DOI 10.17487/RFC5520, April 2009,
+              <http://www.rfc-editor.org/info/rfc5520>.
+
+   [RFC5553]  Farrel, A., Ed., Bradford, R., and JP. Vasseur, "Resource
+              Reservation Protocol (RSVP) Extensions for Path Key
+              Support", RFC 5553, DOI 10.17487/RFC5553, May 2009,
+              <http://www.rfc-editor.org/info/rfc5553>.
+
+   [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, DOI 10.17487/RFC6001, October 2010,
+              <http://www.rfc-editor.org/info/rfc6001>.
+
+   [RFC6060]  Fedyk, D., Shah, H., Bitar, N., and A. Takacs,
+              "Generalized Multiprotocol Label Switching (GMPLS) Control
+              of Ethernet Provider Backbone Traffic Engineering (PBB-
+              TE)", RFC 6060, DOI 10.17487/RFC6060, March 2011,
+              <http://www.rfc-editor.org/info/rfc6060>.
+
+   [RFC6511]  Ali, Z., Swallow, G., and R. Aggarwal, "Non-Penultimate
+              Hop Popping Behavior and Out-of-Band Mapping for RSVP-TE
+              Label Switched Paths", RFC 6511, DOI 10.17487/RFC6511,
+              February 2012, <http://www.rfc-editor.org/info/rfc6511>.
+
+   [RFC6790]  Kompella, K., Drake, J., Amante, S., Henderickx, W., and
+              L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
+              RFC 6790, DOI 10.17487/RFC6790, November 2012,
+              <http://www.rfc-editor.org/info/rfc6790>.
+
+   [RFC7260]  Takacs, A., Fedyk, D., and J. He, "GMPLS RSVP-TE
+              Extensions for Operations, Administration, and Maintenance
+              (OAM) Configuration", RFC 7260, DOI 10.17487/RFC7260, June
+              2014, <http://www.rfc-editor.org/info/rfc7260>.
+
+6.2.  Informative References
+
+   [OBJ-FUN]  Ali, Z., Swallow, G., Filsfils, C., Fang, L., Kumaki, K.,
+              Kunze, R., Ceccarelli, D., and X. Zhang, "Resource
+              ReserVation Protocol-Traffic Engineering (RSVP-TE)
+              Extension for Signaling Objective Function and Metric
+              Bound", Work in Progress, draft-ali-ccamp-rc-objective-
+              function-metric-bound-05, February 2014.
+
+
+
+
+
+Margaria, et al.             Standards Track                   [Page 13]
+
+RFC 7570               General ERO LSP Parameters              July 2015
+
+
+   [RFC4990]  Shiomoto, K., Papneja, R., and R. Rabbat, "Use of
+              Addresses in Generalized Multiprotocol Label Switching
+              (GMPLS) Networks", RFC 4990, DOI 10.17487/RFC4990,
+              September 2007, <http://www.rfc-editor.org/info/rfc4990>.
+
+   [RFC6163]  Lee, Y., Ed., Bernstein, G., Ed., and W. Imajuku,
+              "Framework for GMPLS and Path Computation Element (PCE)
+              Control of Wavelength Switched Optical Networks (WSONs)",
+              RFC 6163, DOI 10.17487/RFC6163, April 2011,
+              <http://www.rfc-editor.org/info/rfc6163>.
+
+   [RFC7571]  Dong, J., Chen, M., Li, Z., and D. Ceccarelli, "GMPLS
+              RSVP-TE Extensions for Lock Instruct and Loopback", RFC
+              7571, DOI 10.17487/RFC7571, July 2015,
+              <http://www.rfc-editor.org/info/rfc7571>.
+
+   [RSVP-TE-HOPS]
+              Kern, A. and A. Takacs, "Encoding of Attributes of LSP
+              intermediate hops using RSVP-TE", Work in Progress,
+              draft-kern-ccamp-rsvpte-hop-attributes-00, October 2009.
+
+   [SRLG-COLLECT]
+              Zhang, F., Dios, O., Li, D., Margaria, C., Hartley, M.,
+              and Z. Ali, "RSVP-TE Extensions for Collecting SRLG
+              Information", Work in Progress, draft-ietf-teas-rsvp-te-
+              srlg-collect-00, December 2014.
+
+   [WSON-SIG]
+              Bernstein, G., Xu, S., Lee, Y., Martinelli, G., and H.
+              Harai, "Signaling Extensions for Wavelength Switched
+              Optical Networks", Work in Progress, draft-ietf-ccamp-
+              wson-signaling-10, March 2015.
+
+Acknowledgments
+
+   The authors would like to thank Lou Berger for his directions and
+   Attila Takacs for inspiring [RSVP-TE-HOPS].  The authors also thank
+   Dirk Schroetter for his contribution to the initial draft versions of
+   this document.
+
+
+
+
+
+
+
+
+
+
+
+
+Margaria, et al.             Standards Track                   [Page 14]
+
+RFC 7570               General ERO LSP Parameters              July 2015
+
+
+Authors' Addresses
+
+   Cyril Margaria (editor)
+   Juniper
+   200 Somerset Corporate Boulevard, Suite 4001
+   Bridgewater, NJ  08807
+   United States
+
+   Email: cmargaria@juniper.net
+
+
+   Giovanni Martinelli
+   Cisco
+   via Philips 12
+   Monza  20900
+   Italy
+
+   Phone: +39 039 209 2044
+   Email: giomarti@cisco.com
+
+
+   Steve Balls
+   Metaswitch
+   100 Church Street
+   Enfield  EN2 6BQ
+   United Kingdom
+
+   Phone: +44 208 366 1177
+   Email: steve.balls@metaswitch.com
+
+
+   Ben Wright
+   Metaswitch
+   100 Church Street
+   Enfield  EN2 6BQ
+   United Kingdom
+
+   Phone: +44 208 366 1177
+   Email: Ben.Wright@metaswitch.com
+
+
+
+
+
+
+
+
+
+
+
+
+Margaria, et al.             Standards Track                   [Page 15]
+