RFC 7570

Label Switched Path (LSP) Attribute in the Explicit Route Object (ERO)

📅 published July 2015, from ietf

RFC 7570 🎀 Label Switched Path (LSP) Attribute in the Explicit Route Object (ERO)

Okay bestie, let's get into RFC 7570 💅 It's a Standards Track document from the IETF, dated July 2015, and it's all about giving per-hop attributes a proper home in the ERO. Editor is C. Margaria (Juniper) 🌸, with co-authors G. Martinelli (Cisco), S. Balls and B. Wright (both Metaswitch) 🫶. It's ISSN 2070-1721. The header doesn't say it obsoletes or updates any other RFC, so it's a fresh standalone ✨

Abstract ✨

RFC 5420 lets RSVP-TE specify or record generic attributes that apply to the whole path of a Label Switched Path (LSP). This document extends the RSVP Explicit Route Object (ERO) and Record Route Object (RRO) so they can specify or record generic attributes that apply to one given hop 🦋

Status of This Memo 🌈

This is an Internet Standards Track document. 💖

It's a product of the Internet Engineering Task Force (IETF), it represents the consensus of the IETF community, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication. If you want more on Internet Standards, check Section 2 of RFC 5741.

Info about the current status, any errata, and how to send feedback lives at http://www.rfc-editor.org/info/rfc7570 🍓

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) as they stand on the publication date. Please read these carefully, because they spell out your rights and restrictions for this document. Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License ⭐

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 using the Explicit Route Object (ERO) and its related subobjects, as defined in [RFC3209], [RFC3473], [RFC3477], [RFC4873], [RFC4874], [RFC5520], and [RFC5553]. Several documents have spotted the need for attributes that can target specific hops along an LSP's path, including [RFC6163], [WSON-SIG], [RFC7571], or [OBJ-FUN]. This document gives all of those a generic mechanism to lean on 🫶

RSVP already supports generic extension of LSP attributes in [RFC5420]. To support current and future ERO constraint extensions, this document adds a way to define per-hop attributes ✨

The document describes a generic mechanism for carrying information tied to specific nodes when signaling an LSP. It doesn't restrict what that information can be used for, so it's very flexible 💅 The approach builds on the LSP attributes from [RFC5420] and lets attributes be expressed in both the ERO and the Secondary Explicit Route Objects (SEROs). A new ERO subobject is defined, and it holds 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 you use it, it's carried in the ERO or SERO. It follows the standard format of an ERO subobject.

2.1. Encoding 🔥

The length is variable, and the content is a list of Hop Attributes TLVs defined in Section 2.2. The size of the ERO subobject caps the size of the Hop Attributes TLV at 250 bytes. The typical size of the currently defined and upcoming LSP_ATTRIBUTE TLVs that apply to a specific hop (WSON_SIGNALING, Objective Function (OF), and Metric) is not expected to go over that limit ⭐

The ERO Hop Attributes subobject is laid out like this 🧚

   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 fields work the same way they do 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. It MUST NOT be changed when a node processes the ERO, and it MUST be ignored on the node addressed by the preceding ERO subobjects 🙈
  • R: This bit reflects the LSP_REQUIRED_ATTRIBUTE and LSP_ATTRIBUTE semantics defined in [RFC5420]. When it's set, it means the required hop attributes need to be processed by the node. When it's cleared, it means the hop attributes aren't 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 the defined flags is valid for use in an 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 valid flags are defined in Section 4.3 ✨

The presence and ordering rule for the Attribute Flags TLV in an ERO Hop Attributes subobject is defined by each Flag. A document that defines a flag for use in an Attribute Flags TLV carried in the ERO Hop Attributes subobject has to describe:

  • after which kinds of ERO subobject the flag is valid,
  • if ordering of the flag and other ERO subobjects associated with the same hop (e.g., Label subobjects) is significant,
  • if ordering is significant, how the flag is interpreted in association with the preceding subobjects, and
  • any flag modification rules that might apply 🌈

2.3. Procedures

okay so the ERO is basically a list of subobjects, and each one is a waypoint on the path 🛤️. A waypoint can name an entity, an abstract node, or a link. The identifying subobject types are defined across [RFC3209], [RFC3477], [RFC4873], [RFC4874], [RFC5520], and [RFC5553] 💅

[RFC3473] tweaked the ERO list too. It lets one or two Label subobjects get tucked in after a subobject that identifies a link ✨

Now the new part: one or more ERO Hop Attributes subobjects for 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 in an ERO Hop Attributes subobject apply to the immediately preceding subobject(s) in the ERO list. So it always reads back to the hop right before it 🦋

If you're writing a document that defines a specific Hop Attributes TLV, you have to spell out a few things:

  • after which kinds of ERO subobject they are valid,
  • if ordering of the Hop Attributes subobject and other ERO subobjects associated with the same hop (e.g., Label subobjects) is significant,
  • if ordering is significant, how the attribute is interpreted in association with the preceding ERO subobjects, and
  • any TLV modification rules that might apply.

For instance, subobject presence rules can be defined by describing rules similar to [RFC4990], Section 6.1 🌸

Now the drama 😭. If a node is processing an ERO Hop Attributes subobject and doesn't support handling it, it behaves the way [RFC3209] says to when it hits an unrecognized ERO subobject. That node returns a PathErr with Error Code Routing Error and Error Value Bad EXPLICIT_ROUTE object, with the EXPLICIT_ROUTE object included. That object gets truncated (on the left) down to the offending unrecognized subobject. Iconic error handling, no cap 💀

When the R bit is set, a node MUST examine the attributes TLV in the subobject using the rules in [RFC5420], Section 5.2. When the R bit is not set, a node MUST examine the attributes TLV in the subobject using the rules in [RFC5420], Section 4.2 👑

A node processing an ERO Hop Attributes subobject whose Hop Attributes TLV is 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. That object gets truncated (on the left) down to the offending malformed subobject. A processing node MUST NOT originate a Hop Attributes TLV longer than the ERO Hop Attributes subobject. And the processing of the Hop Attributes TLVs SHOULD be described in the documents that define them 🫶

3. RRO Hop Attributes Subobject ✨

Sometimes it really matters to figure out whether a node has processed an OPTIONAL hop attribute 🔍

3.1. Encoding

The RRO Hop Attributes subobject is OPTIONAL 🌈 If you use it, it's carried in the RECORD_ROUTE object, and it uses the standard format of an RRO subobject.

Here's the layout:

    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 fields work the way [RFC3209], Section 4.4.1 defines them. The Type for the RRO Hop Attributes subobject is 35. The Hop Attributes TLVs are encoded as Section 2.2 describes 🍓

  • 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] stay exactly the same 💖 The RRO Hop Attributes subobject MUST be pushed after the RRO Attributes subobject (if present), as defined in [RFC5420]. It MAY be present between a pair of subobjects that identify the Label Switching Router (LSR) or links. Unless local policy applies, all of these subobjects SHOULD be forwarded unmodified by transit LSRs 🧚

It's noted that a node (e.g., a domain edge node) MAY edit the RRO to prune or modify it, including the RRO Hop Attributes subobject, before forwarding. That can be for confidentiality policy or other reasons, like RRO size reduction 🙈

3.2.2. Reporting Compliance with ERO Hop Attributes

If an LSR wants to say that an ERO hop attribute has been considered, or to report an extra attribute, it can add an RRO Hop Attributes subobject with the Hop Attributes TLV that describes the attribute being reported 📣 The requirement to report compliance MUST be specified in the document that defines how a hop attribute is used.

3.2.3. Compatibility with RRO Attributes Subobject

The RRO Hop Attributes subobject levels up the RRO Attributes subobject defined in [RFC5420], Section 7.2, because it lets the node report the attribute value. The mechanism in this document is compatible with the RRO Attributes subobject, following these 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 wants to report the attributes, it SHOULD use the RRO Hop Attributes subobject and SHOULD NOT use the RRO Attributes subobject. Ingress nodes that don't support 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 both of these conditions are met:

  • The attribute and its corresponding flag are 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.

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 the one 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 🌈 This document adds a new column to the registry. The column shows whether the flag is allowed in an Attribute Flags TLV carried in the ERO Hop Attributes subobject. The column's heading is "ERO", and the registry has been updated like this:

 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 💜

4.4. Existing LSP Attribute TLVs 📋✨

Okay bestie, so IANA looks after the "Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Parameters" registry, which lives at http://www.iana.org/assignments/rsvp-te-parameters 🗂️💖 Inside it, the "Attributes TLV Space" registry tracks the following, as defined in [RFC5420]:

  • TLV Type (T-field value)
  • TLV Name
  • Whether allowed on LSP_ATTRIBUTES object
  • Whether allowed on LSP_REQUIRED_ATTRIBUTES object

Per this document, IANA has added one more field for each TLV in the RSVP TLV type identifier registry:

  • Whether allowed on LSP Hop Attributes ERO subobject

The existing registry has been updated for the existing TLVs, and here's the deal. 💅 The abbreviations are:

  • 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 🔐🚨

Okay this part is SERIOUS, bestie 😭 This document adds a new subobject to the EXPLICIT_ROUTE and ROUTE_RECORD objects that ride inside RSVP messages used in MPLS and GMPLS signaling. It's built on top of [RFC3209] and [RFC5420] and it does not introduce any new security (it's not a security feature, so don't go thinking it is 🙈). The existing security considerations in [RFC2205], [RFC3209], [RFC3473], and [RFC5420] still totally apply.

Now, as with any RSVP-TE signaling request, the procedures in this document let functional preferences get sent and reported for a specific node 🎀 The mechanism added here does give more control over LSP attributes at a given node, so a node SHOULD check the hop attributes against its policies and admission procedures, the same way it does with any other input. 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. Here's the tea ☕: this can reveal information about the LSP request and status to anyone with unauthorized access. The mechanism in this document doesn't make that problem any worse, and the only real fix is encrypting the content of the whole signaling message 🔒

Also, reporting attributes using the RRO can reveal details about a node that the operator wants kept 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

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.
  • [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. Iconic behaviour 👑🌸

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

That's the whole RFC, bestie! 🌈💖

📦 where this page comes from