diff options
Diffstat (limited to 'doc/rfc/rfc7570.txt')
| -rw-r--r-- | doc/rfc/rfc7570.txt | 843 |
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] + |