RFC 4206

Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)

📅 published October 2005, from ietf

RFC 4206 🎀 Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)

The title block, bestie ✨

  • Series: Network Working Group 🌸
  • Authors: K. Kompella and Y. Rekhter, both from Juniper Networks 💅
  • Date: October 2005 📅
  • Category: Standards Track 👑
  • Obsoletes / Updates: the original title block doesn't list either one, so there's nothing to report here 🙈

Status of This Memo 📜

Okay so this one's an Internet standards track protocol spec for the Internet community 🦋 It's asking for discussion and suggestions for improvements, so bring your ideas! If you want to know where this protocol sits in standardization and status, check the current edition of the "Internet Official Protocol Standards" (STD 1) 🧚 And distribution of this memo is unlimited, so share it with everyone 💜

Copyright (C) The Internet Society (2005).

Abstract 🌈

Okay so here's the problem: GMPLS needs to scale 📈 One way to help is to bundle up Label Switched Paths (LSPs) by building a hierarchy of them 🍓 Here's how it goes:

  • a Label Switching Router (LSR) creates a Traffic Engineering Label Switched Path (TE LSP) 🛠️
  • the LSR forms a forwarding adjacency (FA) out of that LSP, by advertising it as a Traffic Engineering (TE) link into the same instance of ISIS/OSPF that was used to create the LSP 📣
  • other LSRs are allowed to use FAs for their path computation 🧠
  • LSPs that other LSRs started can get nested inside that LSP, using the label stack construct 🪆

This document describes the mechanisms to make all of that happen ✨

Table of Contents 🗂️

   1. Overview ........................................................2
   2. Specification of Requirements ...................................3
   3. Routing Aspects .................................................4
      3.1. Traffic Engineering Parameters .............................4
           3.1.1. Link Type (OSPF Only) ...............................5
           3.1.2. Link ID (OSPF Only) .................................5
           3.1.3. Local and Remote Interface IP Address ...............5
           3.1.4. Local and Remote Link Identifiers ...................5
           3.1.5. Traffic Engineering Metric ..........................5
           3.1.6. Maximum Bandwidth ...................................5
           3.1.7. Unreserved Bandwidth ................................5
           3.1.8. Resource Class/Color ................................5
           3.1.9. Interface Switching Capability ......................6
           3.1.10. SRLG Information ...................................6
   4. Other Considerations ............................................6
   5. Controlling FA-LSPs Boundaries ..................................7
      5.1. LSP Regions ................................................7
   6. Signalling Aspects ..............................................8
      6.1. Common Procedures ..........................................8
           6.1.1. RSVP-TE .............................................8
           6.1.2. CR-LDP ..............................................9
      6.2. Specific Procedures .......................................10
      6.3. FA-LSP Holding Priority ...................................11
   7. Security Considerations ........................................11
   8. Acknowledgements ...............................................12
   9. Normative References ...........................................12
   10. Informative References ........................................13

1. Overview 🦋

Okay so an LSR uses GMPLS TE procedures to create and keep an LSP alive 💖 Then, if local configuration says so, it can announce that LSP as a TE link into the same GMPLS control plane instance (well, its ISIS/OSPF part) that built it 📣 We call that link a "forwarding adjacency" (FA) 🫶 The LSP itself is the "forwarding adjacency LSP", or just FA-LSP 🌸

Here's the key bit: an FA-LSP is both created and used as a TE link by exactly the same GMPLS control plane instance 👑 So the FA idea only works when that's the case, full stop 💅 Also, an FA is a TE link between two GMPLS nodes, and its path can go through zero or more (G)MPLS nodes in that same control plane instance 🧚

Nodes joined by a "basic" TE link might have a routing adjacency 🔗 But nodes joined by an FA usually won't 🙈 And any TE link, basic or FA, has to have a signaling adjacency before it can set up an LSP across it 🎀

Creating and tearing down an FA and its FA-LSP can be triggered from outside GMPLS, like configuration on the LSR at the head-end of the adjacency 🛠️ Or it can happen inside GMPLS, like when that head-end LSR gets LSP setup requests from other LSRs 📨

ISIS/OSPF floods FA info the same way it floods info about any other link 📣 So an LSR ends up with FAs and basic TE links in its TE link state database 🗃️

When an LSR computes a path, it uses both basic TE links and FAs 🧠 After the path is computed, the LSR uses RSVP/CR-LDP [RSVP-TE, CR-LDP] to set up label bindings along it 🏷️

This document defines the mechanisms and procedures for all of that 💜 They cover both the routing side (ISIS/OSPF) and the signalling side (RSVP/CR-LDP) 🌈

Heads up: an LSP might get advertised as a point-to-point link into ISIS or OSPF, for normal SPF use by nodes other than the head-end ⚠️ That's similar in spirit to an FA, but it's out of scope for this document 🙅‍♀️

Also out of scope: setups where one instance of the GMPLS control plane creates and maintains an LSP, and a different instance uses it as a (TE) link 🚫

2. Specification of Requirements 📏

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 BCP 14, RFC 2119 [RFC2119] 🎀

3. Routing Aspects 🛣️

This section is all about building FAs out of LSPs, and how ISIS/OSPF handles them 🧩 Specifically, it covers how to construct the info needed to advertise LSPs as links into ISIS/OSPF 📣 The rules for creating and tearing down those LSPs live in Section 5, "Controlling FA-LSPs boundaries" 💖

FAs can be represented as either unnumbered or numbered links 🔢 If an FA is numbered with IPv4 addresses, both its local and remote IPv4 addresses come out of a /31 allocated by the LSR that originates the FA-LSP 🫧 The head-end address of the FA-LSP is the IPv4 tunnel sender address, and the remote (tail-end) address can be inferred from that 🧠 If the LSP is bidirectional, the tail-end can work out which addresses to assign to the reverse FA 🪞

Now, say multiple LSPs all start on one LSR and all end on another LSR 🌊 At one end of the spectrum, the head-end LSR can merge all of them into a single FA using Link Bundling (see [BUNDLE]) 🧺 At the other end, each LSP can be advertised as its own adjacency 🦋

When an FA is created through administrative control (static provisioning), its FA-LSP attributes have to come from configuration ⚙️ The attributes that may be configured are: the head-end address (if left unconfigured, it defaults to the head-end LSR's Router ID), the tail-end address, and bandwidth and resource colors constraints 🎨 The path the FA-LSP takes can be computed by the LSR at the FA-LSP's head-end, or specified by explicit configuration 🗺️ Which one happens is decided by configuration 🔧

When an FA is created dynamically, its FA-LSP attributes are inherited from the LSP that triggered its creation 🧬 The FA-LSP's bandwidth must be at least as big as that triggering LSP's, but it can be bigger if only discrete bandwidths are available for the FA-LSP 📦 For dynamically provisioned FAs in general, a policy-based mechanism may be needed to attach attributes to the FA-LSPs 🧑‍⚖️

3.1. Traffic Engineering Parameters 🎚️

Here we describe the Traffic Engineering parameters (see [OSPF-TE] and [ISIS-TE]) for FAs 💅

The Link Type of an FA is set to point-to-point ➡️

The Link ID is set to the Router ID of the FA-LSP's tail-end 🪪

3.1.3. Local and Remote Interface IP Address 📍

If the FA is going to be numbered, the local interface IP address (OSPF) or IPv4 interface address (ISIS) is set to the FA-LSP's head-end address 🏁 The remote interface IP address (OSPF) or IPv4 neighbor address (ISIS) is set to the FA-LSP's tail-end address 🎯

For an unnumbered FA, how the local and remote link identifiers get assigned and handled is specified in [UNNUM-RSVP] and [UNNUM-CRLDP] 📚

3.1.5. Traffic Engineering Metric 📏

By default, the TE metric on the FA is set to max(1, (the TE metric of the FA-LSP path) - 1) 🧮 That makes the FA attractive to traffic over setting up a brand-new LSP 🧲 The head-end of the FA can override this through configuration 🛠️

3.1.6. Maximum Bandwidth 📊

By default, the Maximum Reservable Bandwidth and the initial Maximum LSP Bandwidth for all priorities of the FA are set to the bandwidth of the FA-LSP 💪 The head-end of the FA can override these through configuration 🔧 Just note that the Maximum LSP Bandwidth at any one priority should be no more than the FA-LSP's bandwidth ⚠️

3.1.7. Unreserved Bandwidth 🫙

The initial unreserved bandwidth for all priority levels of the FA is set to the bandwidth of the FA-LSP 💧

3.1.8. Resource Class/Color 🎨

By default, an FA has no resource colors (administrative groups) 🙅‍♀️ The head-end of the FA can override this with configuration 🛠️

3.1.9. Interface Switching Capability 🔀

The near-end Interface Switching Capability of an FA is the near-end Interface Switching Capability of the first link in its FA-LSP 🥇

When the near-end Interface Switching Capability field is PSC-1, PSC-2, PSC-3, or PSC-4, the specific info includes Interface MTU and Minimum LSP Bandwidth 📐 The Interface MTU is the minimum MTU along the FA-LSP's path 📉 The Minimum LSP Bandwidth is the bandwidth of the LSP 🌟

3.1.10. SRLG Information 🦋

okay so an FA advertisement can carry info about SRLGs (Shared Risk Link Groups) for the path that the FA-LSP tied to that FA takes 🧚. Other LSRs may use this info for path calculation, which is lowkey so useful 💅. What's carried is the union of the SRLGs of the underlying TE links that make up the FA-LSP path. In IS-IS it lives in the SRLG TLV, and in OSPF it lives in the SRLG sub-TLV of the TE Link TLV. For the full format details, go check [GMPLS-ISIS, GMPLS-OSPF] 🤓.

The underlying path info can change over time, through configuration updates or dynamic route modifications, and when it does, the SRLG TLV can change too 🔄✨.

If FAs are bundled (via link bundling), and the resulting bundled link carries an SRLG TLV, then it MUST be the case that the list of SRLGs in the underlying path, followed by each of the FA-LSPs that form the component links, is the same. The exact paths don't need to be the same though 🙈💖.

4. Other Considerations 🌷

It is expected that FAs will not be used for establishing ISIS/OSPF peering relation between the routers at the ends of the adjacency. So FAs aren't there to make the routing neighbours 🫶.

Sometimes you might want FAs to be used only in Traffic Engineering path computations, and that's totally a thing 🔥. In IS-IS, you can do this by setting the default metric of the extended IS reachability TLV for the FA to the maximum link metric (2^24 - 1). In OSPF, you can do it by not advertising the link as a regular LSA, and only advertising it as a TE opaque LSA 💅🌈.

5. Controlling FA-LSPs Boundaries 🎀

To make it easier to control the boundaries of FA-LSPs, this document introduces two new mechanisms: Interface Switching Capability (see [GMPLS-ISIS, GMPLS-OSPF]), and "LSP region" (or just "region") 🧁.

5.1. LSP Regions 🌸

The info carried in the Interface Switching Capabilities is used to build LSP regions and to figure out where the regions' boundaries are, like this 👑.

First, define an ordering among interface switching capabilities, like so:

PSC-1 < PSC-2 < PSC-3 < PSC-4 < TDM < LSC < FSC

Given two interfaces if-1 and if-2 with interface switching capabilities isc-1 and isc-2 respectively, say that if-1 < if-2 iff isc-1 < isc-2 or isc-1 == isc-2 == TDM, and if-1's max LSP bandwidth is less than if-2's max LSP bandwidth. It's giving ordering drama 💀✨.

Now suppose an LSP's path is as follows:

node-0, link-1, node-1, link-2,
node-2, ..., link-n, node-n.

For link-i, denote by [link-i, node-(i-1)] the interface that connects link-i to node-(i-1), and by [link-i, node-i] the interface that connects link-i to node-i 🦋.

If [link-(i+1), node-i)] < [link-(i+1), node-(i+1)], we say that the LSP has crossed a region boundary at node-i. With respect to that LSP path, the LSR at node-i is an edge LSR 🚧. The 'other edge' of the region with respect to the LSP path is node-k, where k is the smallest number greater than i such that [link-(i+1), node-(i+1)] equal [link-k, node-(k-1)], and [link-k, node-(k-1)] > [link-k, node-k]. Big brain math, bestie 🧠💖.

Path computation may take region boundaries into account when computing a path for an LSP. For example, path computation may restrict the path taken by an LSP to only the links whose Interface Switching Capability is PSC-1 🍓.

Note that an interface may have multiple Interface Switching Capabilities. In that case, the test of whether if-i < if-j depends on the Interface Switching Capabilities chosen for if-i and if-j, and that in turn determines whether or not there is a region boundary at node-i. It's a whole chain reaction, periodt 💅🔥.

6. Signalling Aspects 💌

In this section we describe procedures that an LSR at the head-end of an FA uses for handling LSP setup originated by other LSR. Basically, this is the head-end's to-do list 📝.

As we mentioned before, establishment and termination of FA-LSPs may be triggered either by mechanisms outside of GMPLS (e.g., via administrative control), or by mechanisms within GMPLS (e.g., as a result of the LSR at the edge of an aggregate LSP receiving LSP setup requests originated by some other LSRs beyond LSP aggregate and its edges). Procedures described in Section 6.1, "Common Procedures", apply to both cases. Procedures described in Section 6.2, "Specific Procedures", apply only to the latter case 🫶.

6.1. Common Procedures 🧚

For the purpose of processing the ERO in a Path/Request message of an LSP that is to be tunneled over an FA, an LSR at the head-end of the FA-LSP views the LSR at the tail of that FA-LSP as adjacent (one IP hop away). Tiny distance, big vibes 🌟.

How this is to be achieved for RSVP-TE and CR-LDP is described in the following subsections 👀.

In either case (RSVP-TE or CR-LDP), when an LSP is tunneled through an FA-LSP, the LSR at the head-end of the FA-LSP subtracts the LSP's bandwidth from the unreserved bandwidth of the FA 🍰.

In the presence of link bundling (when link bundling is applied to FAs), when an LSP is tunneled through an FA-LSP, the LSR at the head-end of the FA-LSP also needs to adjust Max LSP bandwidth of the FA 💜.

6.1.1. RSVP-TE 🦋

If one uses RSVP-TE to signal an LSP to be tunneled over an FA-LSP, then the Path message MUST contain an IF_ID RSVP_HOP object [GRSVP-TE, GSIG] instead of an RSVP_HOP object, and the data interface identification MUST identify the FA-LSP 🎀.

The preferred method of sending the Path message is to set the destination IP address of the Path message to the computed NHOP for that Path message. This NHOP address must be a routable address. In the case of separate control and data planes, this must be a control plane address 🌈.

Furthermore, the IP header for the Path message MUST NOT have the Router Alert option. The Path message is intended to be IP-routed to the tail-end of the FA-LSP without being intercepted and processed as an RSVP message by any of the intermediate nodes. No sneaky middlemen allowed 🙅‍♀️✨.

Finally, the IP TTL vs. RSVP TTL check MUST NOT be made. In general, if the IF_ID RSVP_HOP object is used, this check must be disabled, as the number of hops over the control plane may be greater than one. Instead, the following check is done by the receiver Y of the IF_ID RSVP_HOP object:

  1. Make sure that the data interface identified in the IF_ID RSVP_HOP object actually terminates on Y.
  2. Find the "other end" of the above data interface, say X. Make sure that the PHOP in the IF_ID RSVP_HOP object is a control channel address that belongs to the same node as X.

How check #2 is carried out is beyond the scope of this document. Suffice it to say that it may require a Traffic Engineering Database, or the use of LMP [LMP], or yet other means 🤷‍♀️💅.

An alternative method is to encapsulate the Path message in an IP tunnel (or, in the case that the Interface Switching Capability of the FA-LSP is PSC[1-4], in the FA-LSP itself), and unicast the message to the tail-end of the FA-LSP, without the Router Alert option. This option may be needed if intermediate nodes process RSVP messages regardless of whether the Router Alert option is present. Options, options 🎁.

A PathErr sent in response to a Path message with an IF_ID RSVP_HOP object SHOULD contain an IF_ID HOP object. (Note: a PathErr does not normally carry an RSVP_HOP object, but in the case of separated control and data, it is necessary to identify the data channel in the PathErr message 🙈.)

The Resv message back to the head-end of the FA-LSP (PHOP) is IP-routed to the PHOP in the Path message. If necessary, Resv Messages MAY be encapsulated in another IP header whose destination IP address is the PHOP of the received Path message 🫧.

6.1.2. CR-LDP 🍓

If one uses CR-LDP to signal an LSP to be tunneled over an FA-LSP, then the Request message MUST contain an IF_ID TLV [GCR-LDP] object, and the data interface identification MUST identify the FA-LSP 💖.

Furthermore, the head-end LSR must create a targeted LDP session with the tail-end LSR. The Request (Mapping) message is unicast from the head-end (tail-end) to the tail-end (head-end) 🦋✨.

6.2. Specific Procedures 🌟

When an LSR receives a Path/Request message, the LSR determines whether it is at the edge of a region with respect to the ERO carried in the message. The LSR does this by looking up the interface switching capabilities of the previous hop and the next hop in its IGP database, and comparing them using the relation defined in this section. If the LSR is not at the edge of a region, the procedures in this section do not apply. Main character check: are you at the edge? 👑.

If the LSR is at the edge of a region, it must then determine the other edge of the region with respect to the ERO, again using the IGP database. The LSR then extracts (from the ERO) the subsequence of hops from itself to the other end of the region 🗺️.

The LSR then compares the subsequence of hops with all existing FA-LSPs originated by the LSR. If a match is found, that FA-LSP has enough unreserved bandwidth for the LSP being signaled, the L3PID of the FA-LSP is compatible with the L3PID of the LSP being signaled, and the LSR uses that FA-LSP as follows. The Path/Request message for the original LSP is sent to the egress of the FA-LSP, not to the next hop along the FA-LSP's path. The PHOP in the message is the address of the LSR at the head-end of the FA-LSP. Before sending the Path/Request message, the ERO in that message is adjusted by removing the subsequence of the ERO that lies in the FA-LSP, and replacing it with just the end point of the FA-LSP. Matchmaking, but make it networking 💘.

Otherwise (if no existing FA-LSP is found), the LSR sets up a new FA-LSP. That is, it initiates a new LSP setup just for the FA-LSP. Note that the new LSP may traverse either 'basic' TE links or FAs 🌈.

After the LSR establishes the new FA-LSP, the LSR announces this LSP into IS-IS/OSPF as an FA 📣.

The unreserved bandwidth of the FA is computed by subtracting the bandwidth of sessions pending the establishment of the FA-LSP associated from the bandwidth of the FA-LSP. Math check, bestie 🧮💅.

An FA-LSP could be torn down by the LSR at the head-end of the FA-LSP as a matter of policy local to the LSR. It is expected that the FA-LSP would be torn down once there are no more LSPs carried by the FA-LSP. When the FA-LSP is torn down, the FA associated with the FA-LSP is no longer advertised into IS-IS/OSPF. Bye bye, FA 👋🥀.

6.3. FA-LSP Holding Priority 🎀

The value of the holding priority of an FA-LSP must be the minimum of the configured holding priority of the FA-LSP and the holding priorities of the LSPs tunneling through the FA-LSP (note that smaller priority values denote higher priority). Thus, if an LSP of higher priority than the FA-LSP tunnels through the FA-LSP, the FA-LSP is itself promoted to the higher priority 🚀. However, if the tunneled LSP is torn down, the FA-LSP need not drop its priority to its old value right away. It may be advisable to apply hysteresis in this case 🫶.

If the holding priority of an FA-LSP is configured, this document restricts it to 0 ✨👑.

7. Security Considerations 🔐

okay bestie, this section is kinda serious ngl 💀 The big plot twist is that the old assumption tying data interfaces to the interface a control message goes out on is no longer valid 😭

That means "sending interface" and "receiving interface" aren't well-defined anymore, since the interface an RSVP message leaves through can change whenever routing changes 🦋. So anything that leans on those ideas, like defining a security association, needs a clearer definition 🫶.

[RFC2747] already has a fix ✨. In Section 2.1, under "Key Identifier", an IP address counts as a valid identifier for the sending (and, by analogy, receiving) interface. RSVP messages for an LSP are sent to an IP address that identifies the next or previous hop, so you can swap every 'sending [receiving] interface' for 'receiver's [sender's] IP address' (respectively) 💅. For example, in Section 4, third paragraph, instead of:

   "Each sender SHOULD have distinct security associations (and keys)
   per secured sending interface (or LIH).  ...  At the sender,
   security association selection is based on the interface through
   which the message is sent."

it should read:

   "Each sender SHOULD have distinct security associations (and keys)
   per secured receiver's IP address. ...  At the sender, security
   association selection is based on the IP address to which the
   message is sent."

Note that CR-LDP doesn't have this issue 🌿. CR-LDP messages are sent over TCP sessions, and nothing assumes those sessions are with direct neighbours 🌸. The recommended mechanism for authentication and integrity of LDP message exchange is the TCP MD5 option [LDP].

Another consequence for RSVP from these changes is that the IP destination address of Path messages gets set to the receiver's address, not the session destination 🧚. So the objections raised in Section 1.2 of [RFC2747] should be revisited to see if IPSec AH is now a viable way to secure RSVP-TE messages 👑.

8. Acknowledgements 🫶

Many thanks to Alan Hannan, whose early discussions with Yakov Rekhter contributed greatly to the notion of Forwarding Adjacencies 🌈. We would also like to thank George Swallow, Quaizar Vohra and Ayan Banerjee 💜.

9. Normative References 📚

  • [GCR-LDP] Ashwood-Smith, P. and L. Berger, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions", RFC 3472, January 2003.
  • [GMPLS-ISIS] Kompella, K., Ed., and Y. Rekhter, Ed., "Intermediate System to Intermediate System (IS-IS) Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4205, October 2005.
  • [GMPLS-OSPF] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, October 2005.
  • [GRSVP-TE] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
  • [GSIG] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
  • [ISIS-TE] Smit, H. and T. Li, "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784, June 2004.
  • [LDP] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B. Thomas, "Label Distribution Protocol", RFC 3036, January 2001.
  • [OSPF-TE] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
  • [UNNUM-CRLDP] Kompella, K., Rekhter, Y., and A. Kullberg, "Signalling Unnumbered Links in CR-LDP (Constraint-Routing Label Distribution Protocol)", RFC 3480, February 2003.
  • [UNNUM-RSVP] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", RFC 3477, January 2003.
  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.

10. Informative References 🦋

  • [BUNDLE] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
  • [LMP] Lang, L., Ed., "Link Management Protocol (LMP)", RFC 4204, October 2005.

Authors' Addresses 💌

   Kireeti Kompella
   Juniper Networks, Inc.
   1194 N. Mathilda Ave
   Sunnyvale, CA 94089

   EMail: kireeti@juniper.net


   Yakov Rekhter
   Juniper Networks, Inc.
   1194 N. Mathilda Ave
   Sunnyvale, CA 94089

   EMail: yakov@juniper.net

Copyright (C) The Internet Society (2005).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

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 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.

Intellectual Property 🔒

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification, can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Acknowledgement 🌸

Funding for the RFC Editor function is currently provided by the Internet Society. 💖

📦 where this page comes from