From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc5710.txt | 675 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 675 insertions(+) create mode 100644 doc/rfc/rfc5710.txt (limited to 'doc/rfc/rfc5710.txt') diff --git a/doc/rfc/rfc5710.txt b/doc/rfc/rfc5710.txt new file mode 100644 index 0000000..b365553 --- /dev/null +++ b/doc/rfc/rfc5710.txt @@ -0,0 +1,675 @@ + + + + + + +Internet Engineering Task Force (IETF) L. Berger +Request for Comments: 5710 LabN +Category: Standards Track D. Papadimitriou +ISSN: 2070-1721 Alcatel Lucent + JP. Vasseur + Cisco + January 2010 + + + PathErr Message Triggered MPLS and GMPLS LSP Reroutes + +Abstract + + This document describes how Resource ReserVation Protocol (RSVP) + PathErr messages may be used to trigger rerouting of Multi-Protocol + Label Switching (MPLS) and Generalized MPLS (GMPLS) point-to-point + Traffic Engineering (TE) Label Switched Paths (LSPs) without first + removing LSP state or resources. Such LSP rerouting may be desirable + in a number of cases, including, for example, soft-preemption and + graceful shutdown. This document describes the usage of existing + Standards Track mechanisms to support LSP rerouting. In this case, + it relies on mechanisms already defined as part of RSVP-TE and simply + describes a sequence of actions to be executed. While existing + protocol definitions can be used to support reroute applications, + this document also defines a new reroute-specific error code to allow + for the future definition of reroute-application-specific error + values. + +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/rfc5710. + + + + + + + + + + +Berger, et al. Standards Track [Page 1] + +RFC 5710 MPLS and GMPLS LSP Reroutes January 2010 + + +Copyright Notice + + Copyright (c) 2010 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. + +Table of Contents + + 1. Introduction ....................................................3 + 1.1. Conventions Used in This Document ..........................4 + 2. Reroute Requests ................................................4 + 2.1. Processing at Requesting Node ..............................4 + 2.1.1. Reroute Request Timeouts ............................5 + 2.2. Processing at Upstream Node ................................6 + 2.3. Processing at Ingress ......................................6 + 3. Example Reroute Requests ........................................7 + 3.1. Node Reroute Request .......................................7 + 3.2. Interface Reroute Request ..................................7 + 3.3. Component Reroute Request ..................................8 + 3.4. Label Reroute Request ......................................9 + 4. IANA Considerations .............................................9 + 5. Security Considerations ........................................10 + 6. References .....................................................10 + 6.1. Normative References ......................................10 + 6.2. Informative References ....................................11 + 7. Acknowledgments ................................................11 + + + + + + + + + + + + + + + + +Berger, et al. Standards Track [Page 2] + +RFC 5710 MPLS and GMPLS LSP Reroutes January 2010 + + +1. Introduction + + The Resource ReserVation Protocol (RSVP), see [RFC2205], has been + extended to support the control of Traffic Engineering (TE) Label + Switched Paths (LSPs) for both Multi-Protocol Label Switching (MPLS) + and Generalized MPLS (GMPLS) in, respectively, [RFC3209] and + [RFC3473]. In all cases, a PathErr message is used to report errors + to nodes upstream of the error-detecting node. As defined in + [RFC2205] and left unmodified by [RFC3209], PathErr messages "do not + change path state in the nodes through which they pass". + Notwithstanding this definition, PathErr messages are most commonly + used to report errors during LSP establishment, i.e., the RSVP-TE + processing that occurs prior to the ingress receiving a Resv message. + (See [RFC5711] for a broader discussion on PathErr message handling.) + Support for such usage was enhanced via the introduction of the + Path_State_Removed flag in [RFC3473], which enables a processing node + to free related LSP state and resources. The usage of PathErr + messages during LSP establishment was further covered in [RFC4920], + which describes in detail how a node may indicate that it or one of + its associated resources should be avoided, i.e., routed around, + during LSP establishment. + + PathErr messages can also be used to support a number of other cases + that can occur after an LSP is established. This document focuses on + the cases where PathErr messages can be used for a node to indicate + that it desires an upstream node to reroute an LSP around the + indicating node or resources associated with the indicating node. + Some examples of such cases are soft-preemption and graceful shutdown + (see [RFC5712] and [GRACEFUL]). + + This document uses the terminology "reroute request" to refer to the + indication by a node that an upstream reroute should take place. + This document describes how a node can initiate a reroute request + without disrupting LSP data traffic or, when so desired, with the + disruption of data traffic and removal of LSP-associated state and + resources. The applicability of this document is limited to point- + to-point LSPs. Support for point-to-multipoint LSPs are for further + study. + + The mechanisms used to indicate reroute requests are derived from the + mechanisms described in [RFC4920] and the error codes defined in + [RFC4736]. This document describes (1) how a non-disruptive reroute + request may be issued and, (2) based on an optional "timeout" period, + how rerouting may be forced by removing LSP state and associated + resources and signaling such removal. While this document describes + how existing protocol definitions can be used to support rerouting, + it also defines a new reroute-specific error code to allow for the + future definition of reroute-application-specific error values. + + + +Berger, et al. Standards Track [Page 3] + +RFC 5710 MPLS and GMPLS LSP Reroutes January 2010 + + +1.1. Conventions Used in This Document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + +2. Reroute Requests + + This section describes how a downstream node can indicate that it + desires a node upstream (along the LSP path) to initiate the + rerouting of an LSP, and how the upstream nodes can respond to such a + request. Initiating nodes, transit nodes, and ingress nodes are + described separately. + +2.1. Processing at Requesting Node + + When a transit or egress node desires to request the rerouting of an + established LSP, it first determines if it can act on the reroute + request locally. Such a check MUST be performed on the condition + that the Explicit Route Object (ERO), see [RFC3209], received in the + LSP's incoming Path message does not preclude LSP rerouting. + Examples of requests that may trigger reroutes are avoiding an + outgoing interface, a component, label resource, or a next hop not + explicitly listed in the ERO. In all cases, the actual repair action + SHOULD be performed after verification that the local policy allows + local repair for that LSP/state. That is, any traffic-rerouting + action (associated to this state) must be initiated and completed + only as allowed by local node policy. + + When the node cannot act locally, it MUST issue a PathErr message + indicating its inability to perform local rerouting. The PathErr + message MUST contain an ERROR_SPEC object of the format defined in + [RFC2205] or [RFC3473]. Such a message MUST include one of the + following combinations of error codes and error values: + + 1. "Notify/Local node maintenance required" to support backwards + compatibility and to reroute around the local node. + + 2. "Notify/Local link maintenance required" to support backwards + compatibility and to reroute around a local interface. + + 3. "Reroute/" for future compatibility + and when backwards compatibility is not a concern. + + + + + + + + +Berger, et al. Standards Track [Page 4] + +RFC 5710 MPLS and GMPLS LSP Reroutes January 2010 + + + The rest of the ERROR_SPEC object is constructed based on the local + rerouting decision and the resource that is to be avoided by an + upstream node. It is important to note that the address and TLVs + carried by the ERROR_SPEC object identify the resource to be avoided + and not the error code and value. + + When the reroute decision redirects traffic around the local node, + the local node MUST be indicated in the ERROR_SPEC object. + Otherwise, i.e., when the reroute decision does not redirect traffic + around the local node, the impacted interface MUST be indicated in + the ERROR_SPEC object and the IF_ID [RFC3473] ERROR_SPEC object + formats SHOULD be used to indicate the impacted interface. + + The IF_ID [RFC3473] ERROR_SPEC object format MUST be used to indicate + a reroute request that is more specific than an interface. The TLVs + defined in [RFC3471], as updated by [RFC3477], [RFC4201], and + [RFC4920] MAY be used to provide specific, additional reroute request + information, e.g., reroute around a specific label. The principles + related to ERROR_SPEC object construction, defined in Section 6.3.1 + of [RFC4920], SHOULD be followed. + +2.1.1. Reroute Request Timeouts + + Reroute request timeouts are used to remove an LSP when there is no + response to a reroute request. A reroute request timeout is used + when an LSP is to be removed at the expiration of the reroute request + timeout period. When such LSP removal is desired, and after + initiating a reroute request, the initiating node MUST initiate a + timeout during which it expects to receive a response to the reroute + request. Valid responses are a PathTear message or a trigger Path + message with an ERO, avoiding the resource that was indicated in the + reroute request. If either type of message is received, the timeout + period MUST be canceled and no further action is needed. Note, + normal refresh processing is not modified by the introduction of + reroute request timeouts. Such processing may result in Path state + being removed during the timeout period, in which case the timeout + period MUST also be canceled. + + If the reroute request timeout is reached, the initiating node MUST + remove the LSP and its associated state and resources. Removal of + LSP state is indicated downstream via a corresponding PathTear + message. Removal is indicated upstream via a PathErr message with + the error code of "Service preempted". The Path_State_Removed flag + MUST be set if supported. When the Path_State_Removed flag is not + supported, a corresponding ResvTear MUST also be sent. + + + + + + +Berger, et al. Standards Track [Page 5] + +RFC 5710 MPLS and GMPLS LSP Reroutes January 2010 + + +2.2. Processing at Upstream Node + + When a transit node's policy permits it to support reroute request + processing and local repair, the node MUST examine incoming PathErr + messages to see it the node can perform a requested reroute. A + reroute request is indicated in a received PathErr message, which + carries one of the error code and value combinations listed above in + Section 2.1. Note that a conformant implementation MUST check for + any of the three combinations listed in Section 2.1. + + A transit node MAY act on a reroute request locally when the ERO + received in the LSP's incoming Path message does not preclude the + reroute. As before, examples include loosely routed LSP next hops. + When the reroute request can be processed locally, standard, local + repair processing MUST be followed. The node SHOULD limit the number + of local repair attempts. Again, the expected norm is for local + repair, and thereby this case, to be precluded due to policy. + + When the transit node supports [RFC4920] and is a boundary node, and + Boundary rerouting is allowed, it SHOULD use a route request as a + trigger to reroute the LSP. (Per [RFC4920], the Flags field of the + LSP_ATTRIBUTES object of the initial Path message indicates "Boundary + rerouting".) In the case the node triggers rerouting, it first MUST + identify an alternate path within the domain. When such a path is + available, the node MUST terminate the PathErr message and issue a + Path message reflecting the identified alternate path. Processing + then continues per [RFC4920]. When an alternate path is not + available, the node cannot act on the reroute request. + + When a transit node cannot act on a reroute request locally, per + standard processing, it MUST propagate the received PathErr message + to the previous hop. + +2.3. Processing at Ingress + + When reroute processing is supported, an ingress node MUST check + received PathErr messages to identify them as indicating reroute + requests. A reroute request is indicated in a received PathErr + message, which carries one of the error code and value combinations + listed above in Section 2.1. Note that a conformant implementation + MUST check for any of the three combinations listed in Section 2.1. + + Upon receiving a reroute request, the ingress MUST attempt to + identify an alternate path, avoiding the node, interface, resource, + etc. identified within the ERROR_SPEC object. When an alternate path + cannot be identified, the reroute request MUST be discarded. When an + + + + + +Berger, et al. Standards Track [Page 6] + +RFC 5710 MPLS and GMPLS LSP Reroutes January 2010 + + + alternate path is identified, a corresponding make-before-break LSP + SHOULD be initiated and standard make-before-break procedures MUST be + followed. + +3. Example Reroute Requests + + This section provides example reroute requests. This section is + informative rather than prescriptive. Reroute requests are always + sent via PathErr messages. As described above, a PathErr message may + contain either an [RFC2205] format ERROR_SPEC object, or an IF_ID + [RFC3473] format ERROR_SPEC object; it is the address and TLVs + carried by the ERROR_SPEC object, and not the error value, that + indicates the resource that is to be avoided by the reroute. + +3.1. Node Reroute Request + + To indicate that the node should be avoided by an upstream node, the + node originating the reroute may format the ERROR_SPEC per [RFC2205], + for example: + + o IPv4 ERROR_SPEC object: Class = 6, C-Type = 1 + + +-------------+-------------+-------------+-------------+ + | IPv4 Error Node Address (4 bytes) | + +-------------+-------------+-------------+-------------+ + | Flags | Error Code | Error Value | + +-------------+-------------+-------------+-------------+ + + The node address is set to the local node's TE router address. Error + code is set to either "Notify/Local node maintenance required" or + "Reroute/". + +3.2. Interface Reroute Request + + To indicate that a numbered interface should be avoided by an + upstream node, the node originating the reroute may format the + ERROR_SPEC per [RFC3473], for example: + + + + + + + + + + + + + + +Berger, et al. Standards Track [Page 7] + +RFC 5710 MPLS and GMPLS LSP Reroutes January 2010 + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Length | Class-Num (6) | C-Type (3) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | IPv4 Error Node Address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Flags | Error Code | Error Value | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type (1) | Length (8) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | IP Address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The node address is set to the local node's TE router address. Error + code is set to either "Notify/Local link maintenance required" or + "Reroute/". IP address is set to the TE + address of the interface to be avoided. + +3.3. Component Reroute Request + + To indicate that an unnumbered component should be avoided by an + upstream node, the node originating the reroute formats the + ERROR_SPEC per [RFC4201], for example: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Length | Class-Num (6) | C-Type (3) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | IPv4 Error Node Address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Flags | Error Code | Error Value | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type (3) | Length (12) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Router ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Interface ID (32 bits) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The node address is set to the local TE address used in the + advertisement of the bundle associated with the component. Error + code is set to either "Notify/Local link maintenance required" or + "Reroute/". Router ID is set to the local + router ID, and Interface ID is the identifier assigned to the + component link by the local node. + + + + +Berger, et al. Standards Track [Page 8] + +RFC 5710 MPLS and GMPLS LSP Reroutes January 2010 + + +3.4. Label Reroute Request + + To indicate that a label should be avoided by an upstream node, the + node originating the reroute may format the ERROR_SPEC per [RFC4920], + for example: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Length | Class-Num (6) | C-Type (3) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | IPv4 Error Node Address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Flags | Error Code | Error Value | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type (1) | Length (8) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | IP Address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type (6) | Length (8) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | DOWNSTREAM_LABEL | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The node address is set to the local node's TE router address. Error + code is set to either "Notify/Local link maintenance required" or + "Reroute/". IP address is set to the TE + address of the interface that supports the label to be avoided. + DOWNSTREAM_LABEL indicates the label to be avoided. + +4. IANA Considerations + + IANA assigned values for namespaces defined in this document and + reviewed in this section. + + IANA made the assignment in the "Error Codes and Globally-Defined + Error Value Sub-Codes" section of the "RSVP Parameters" registry: + + 34 Reroute [RFC5710] + + This error code has the following defined Error Value sub-code: + + 0 = Generic LSP reroute request + + Reroute error values should be allocated based on the following + allocation policy as defined in [RFC5226]. + + + + + +Berger, et al. Standards Track [Page 9] + +RFC 5710 MPLS and GMPLS LSP Reroutes January 2010 + + + Range Registration Procedures + -------- ------------------------ + 0-32767 IETF Consensus + 32768-65535 Private Use + +5. Security Considerations + + Sections 9 of [RFC4920] and [RFC4736] should be used as the starting + point for reviewing the security considerations related to the + formats and mechanisms discussed in this document. This document + introduces a new error code, but this code is functionally equivalent + to existing semantics, in particular, the error code/error value + combinations of "Notify/Local node maintenance required" and + "Notify/Local link maintenance required". As such, this document + introduces no new security considerations beyond what already applies + to these existing formats and mechanisms. Future documents may + define new error values; any considerations specific to those values + should be discussed in the document defining them. +6. References + +6.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and + S. Jamin, "Resource ReSerVation Protocol (RSVP) -- + Version 1 Functional Specification", RFC 2205, September + 1997. + + [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, + V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP + Tunnels", RFC 3209, December 2001. + + [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label + Switching (GMPLS) Signaling Functional Description", RFC + 3471, January 2003. + + [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label + Switching (GMPLS) Signaling Resource ReserVation + Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC + 3473, January 2003. + + [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered + Links in Resource ReSerVation Protocol - Traffic + Engineering (RSVP-TE)", RFC 3477, January 2003. + + + + + +Berger, et al. Standards Track [Page 10] + +RFC 5710 MPLS and GMPLS LSP Reroutes January 2010 + + + [RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling + in MPLS Traffic Engineering (TE)", RFC 4201, October + 2005. + + [RFC4920] Farrel, A., Ed., Satyanarayana, A., Iwata, A., Fujita, + N., and G. Ash, "Crankback Signaling Extensions for MPLS + and GMPLS RSVP-TE", RFC 4920, July 2007. + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + May 2008. + +6.2. Informative References + + [RFC4736] Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang, + "Reoptimization of Multiprotocol Label Switching (MPLS) + Traffic Engineering (TE) Loosely Routed Label Switched + Path (LSP)", RFC 4736, November 2006. + + [GRACEFUL] Ali, Z., Vasseur, JP., Zamfir, A., and J. Newton, + "Graceful Shutdown in MPLS and Generalized MPLS Traffic + Engineering Networks", Work in Progress, September 2009. + + [RFC5711] Vasseur, JP., Ed., Swallow, G., and I. Minei, "Node + Behavior upon Originating and Receiving Resource + Reservation Protocol (RSVP) Path Error Messages", RFC + 5711, January 2010. + + [RFC5712] Meyer, M., Ed. and JP. Vasseur, Ed., "MPLS Traffic + Engineering Soft Preemption", RFC 5712, January 2010. + +7. Acknowledgments + + This document was conceived along with Matthew Meyer. George Swallow + provided valuable feedback. The General Area Review Team (Gen-ART) + review was performed by Francis Dupont. + + + + + + + + + + + + + + + +Berger, et al. Standards Track [Page 11] + +RFC 5710 MPLS and GMPLS LSP Reroutes January 2010 + + +Authors' Addresses + + Lou Berger + LabN Consulting, L.L.C. + Phone: +1-301-468-9228 + EMail: lberger@labn.net + + + Dimitri Papadimitriou + Alcatel Lucent + Francis Wellesplein 1, + B-2018 Antwerpen, Belgium + Phone: +32 3 240-8491 + EMail: Dimitri.Papadimitriou@alcatel-lucent.be + + + JP Vasseur + Cisco Systems, Inc + 11, Rue Camille Desmoulins + L'Atlantis + 92782 Issy Les Moulineaux + France + EMail: jpv@cisco.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Berger, et al. Standards Track [Page 12] + -- cgit v1.2.3