doc: Add RFC documents

1 files changed, 507 insertions, 0 deletions

diff --git a/doc/rfc/rfc7571.txt b/doc/rfc/rfc7571.txt
new file mode 100644
index 0000000..d384d77
--- /dev/null
+++ b/doc/rfc/rfc7571.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                           J. Dong
+Request for Comments: 7571                                       M. Chen
+Category: Standards Track                            Huawei Technologies
+ISSN: 2070-1721                                                    Z. Li
+                                                            China Mobile
+                                                           D. Ceccarelli
+                                                                Ericsson
+                                                               July 2015
+
+
+        GMPLS RSVP-TE Extensions for Lock Instruct and Loopback
+
+Abstract
+
+   This document specifies extensions to Resource Reservation Protocol -
+   Traffic Engineering (RSVP-TE) to support Lock Instruct (LI) and
+   Loopback (LB) mechanisms for Label Switched Paths (LSPs).  These
+   mechanisms are applicable to technologies that use Generalized MPLS
+   (GMPLS) for the control plane.
+
+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/rfc7571.
+
+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.
+
+
+
+Dong, et al.                 Standards Track                    [Page 1]
+
+RFC 7571             RSVP-TE Extensions for LI & LB            July 2015
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
+     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
+   2.  Flag Definitions for LI and LB  . . . . . . . . . . . . . . .   3
+     2.1.  Lock Instruct Indication  . . . . . . . . . . . . . . . .   3
+     2.2.  Extensions for Loopback . . . . . . . . . . . . . . . . .   3
+   3.  Operational Procedures  . . . . . . . . . . . . . . . . . . .   3
+     3.1.  Lock Instruct . . . . . . . . . . . . . . . . . . . . . .   3
+     3.2.  Loopback  . . . . . . . . . . . . . . . . . . . . . . . .   4
+   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
+     4.1.  Attribute Flags . . . . . . . . . . . . . . . . . . . . .   6
+     4.2.  RSVP Error Value Sub-Codes  . . . . . . . . . . . . . . .   6
+     4.3.  Allocation Rule for ERO Subobjects  . . . . . . . . . . .   6
+   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
+   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
+     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
+     6.2.  Informative References  . . . . . . . . . . . . . . . . .   8
+   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   9
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9
+
+1.  Introduction
+
+   The requirements for Lock Instruct (LI) and Loopback (LB) in the
+   Multiprotocol Label Switching Transport Profile (MPLS-TP) are
+   specified in [RFC5860], and the framework of LI and LB is specified
+   in [RFC6371].  A Label Switched Path (LSP) that is locked, using LI,
+   is prevented from carrying user data traffic.  The LB function can
+   only be applied to an LSP that has been previously locked.
+
+   In general, the LI and LB are useful Operations, Administration, and
+   Maintenance (OAM) functions for technologies that use Generalized
+   MPLS (GMPLS) for the control plane, e.g., time-division multiplexing,
+   wavelength-division multiplexing, and packet switching.  It is
+   natural to use and extend the GMPLS control-plane protocol to provide
+   a unified approach for LI and LB provisioning in all these
+   technologies.
+
+   [RFC7487] specifies the RSVP-TE extensions for the configuration of
+   proactive MPLS-TP OAM functions, such as Continuity Check (CC),
+   Connectivity Verification (CV), Delay Measurement (DM), and Loss
+   Measurement (LM).  The provisioning of on-demand OAM functions such
+   as LI and LB are not covered in that document.
+
+   This document specifies extensions to Resource Reservation Protocol-
+   Traffic Engineering (RSVP-TE) to support lock instruct and loopback
+   mechanisms for LSPs.  The mechanisms are applicable to technologies
+
+
+
+
+Dong, et al.                 Standards Track                    [Page 2]
+
+RFC 7571             RSVP-TE Extensions for LI & LB            July 2015
+
+
+   that use GMPLS for the control plane.  For a network supporting MPLS-
+   TP, the mechanisms defined in this document are complementary to
+   [RFC6435].
+
+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.  Flag Definitions for LI and LB
+
+2.1.  Lock Instruct Indication
+
+   In order to indicate the lock/unlock status of the LSP, the A
+   (Administratively down) bit in the Administrative Status
+   (ADMIN_STATUS) Object [RFC3471] [RFC3473] is used.
+
+2.2.  Extensions for Loopback
+
+   In order to indicate the loopback mode of LSP, a new bit flag is
+   defined in the Attribute Flags TLV [RFC5420].
+
+   Loopback flag:
+
+      This flag indicates a particular node on the LSP is required to
+      enter loopback mode.  This can also be used for specifying the
+      loopback state of the node.
+
+      - Bit number: 13
+
+      - Attribute flag carried in Path message: Yes
+
+      - Attribute flag carried in Resv message: No
+
+      - Attribute flag carried in the Record Route Object (RRO)
+      Attributes subobject: Yes
+
+3.  Operational Procedures
+
+3.1.  Lock Instruct
+
+   When an ingress node intends to put an LSP into lock mode, it MUST
+   send a Path message with the Administratively down (A) bit used as
+   specified above and the Reflect (R) bit in the ADMIN_STATUS Object
+   set.
+
+
+
+
+
+Dong, et al.                 Standards Track                    [Page 3]
+
+RFC 7571             RSVP-TE Extensions for LI & LB            July 2015
+
+
+   On receipt of this Path message, the egress node SHOULD try to take
+   the LSP out of service.  If the egress node locks the LSP
+   successfully, it MUST send a Resv message with the A bit in the
+   ADMIN_STATUS Object set.  Otherwise, it MUST send a PathErr message
+   with the Error Code "OAM Problem" [RFC7260] and the new Error Value
+   "Lock Failure", and the following Resv messages MUST be sent with the
+   A bit cleared.
+
+   When an LSP is put in lock mode, the subsequent Path and Resv
+   messages MUST keep the A bit in the ADMIN_STATUS Object set.
+
+   When the ingress node intends to take the LSP out of the lock mode,
+   it MUST send a Path message with the A bit in the ADMIN_STATUS Object
+   cleared.
+
+   On receipt of this Path message, the egress node SHOULD try to bring
+   the LSP back to service.  If the egress node unlocks the LSP
+   successfully, it MUST send a Resv message with the A bit in the
+   ADMIN_STATUS Object cleared.  Otherwise, it MUST send a PathErr
+   message with the Error Code "OAM Problem" [RFC7260] and the new Error
+   Value "Unlock Failure", and the following Resv messages MUST be sent
+   with the A bit set.
+
+   When an LSP is taken out of lock mode, the subsequent Path and Resv
+   messages MUST keep the A bit in the ADMIN_STATUS Object cleared.
+
+3.2.  Loopback
+
+   The loopback request can be sent either to the egress node or to a
+   particular intermediate node.  The mechanism defined in [RFC7570] is
+   used for addressing the loopback request to a particular node on the
+   LSP.  The ingress node MUST ensure that the LSP is in lock mode
+   before it requests setting a particular node on the LSP into loopback
+   mode.
+
+   When an ingress node intends to put a particular node on the LSP into
+   loopback mode, it MUST send a Path message with the Loopback
+   Attribute Flag defined above in the Attribute Flags TLV set.  The
+   mechanism defined in [RFC7570] is used to address the loopback
+   request to the particular node.  The ingress node MUST ensure that
+   the entity at which loopback is intended to occur is explicitly
+   identified by the immediately preceding subobject of the Explicit
+   Route Object (ERO) Hop Attributes subobject.  The Administratively
+   down (A) bit in the ADMIN_STATUS Object MUST be kept set to indicate
+   that the LSP is still in lock mode.
+
+
+
+
+
+
+Dong, et al.                 Standards Track                    [Page 4]
+
+RFC 7571             RSVP-TE Extensions for LI & LB            July 2015
+
+
+   On receipt of this Path message, the target node of the loopback
+   request MUST check if the LSP is in lock mode by verifying that the
+   Administratively down (A) bit is set in the ADMIN_STATUS Object.  If
+   the bit is not set, the loopback request MUST be ignored.  If the bit
+   is set, the node MUST check that the desired loopback entity is
+   explicitly identified by the ERO subobject prior to the ERO Hop
+   Attributes subobject.  Currently, the type value MUST be verified to
+   be less than 32 (i.e., able to identify a specific entity where a
+   loopback can occur; see Section 4.3), and for type values 1 (IPv4
+   prefix) and 2 (IPv6 prefix), the prefix length MUST be 32 and 128,
+   respectively.  If the desired loopback entity is not explicitly
+   identified, the request MUST be ignored and a "Bad EXPLICIT_ROUTE
+   object" error SHOULD be generated.  Otherwise, the node SHOULD try to
+   put the LSP into loopback mode.  The loopback SHOULD be enabled on
+   the entity identified by the ERO subobject immediately prior to the
+   ERO Hop Attributes subobject.  If the immediately preceding subobject
+   is a label subobject [RFC3473], the loopback SHOULD be enabled for
+   the direction indicated by the U bit of the label subobject.
+
+   If the node puts the LSP into loopback mode successfully, it MUST set
+   the Loopback Attribute Flag if it adds, per [RFC7570], an RRO Hop
+   Attributes subobject to the RRO of a Path or Resv message.  The
+   Administratively down (A) bit in the ADMIN_STATUS Object MUST be kept
+   set in the message.  If the node cannot put the LSP into loopback
+   mode, it MUST send a PathErr message with the Error Code "OAM
+   Problem" [RFC7260] and the new Error Value "Loopback Failure".
+
+   When the ingress node intends to take the particular node out of
+   loopback mode, it MUST send a Path message with the Loopback
+   Attribute Flag in the Attribute Flags TLV cleared.  The mechanism
+   defined in [RFC7570] is used to indicate that the particular node
+   SHOULD exit loopback mode for this LSP.  The Administratively down
+   (A) bit in the ADMIN_STATUS Object MUST be kept set to indicate the
+   LSP is still in lock mode.
+
+   On receipt of this Path message, the target node SHOULD try to take
+   the LSP out of loopback mode.  If the node takes the LSP out of
+   loopback mode successfully, it MUST clear the Loopback Attribute Flag
+   in the RRO Hop Attributes subobject and push this subobject onto the
+   RRO object in the corresponding Path or Resv message.  The
+   Administratively down (A) bit in the ADMIN_STATUS Object MUST be kept
+   set in the message.  Otherwise, the node MUST send a PathErr message
+   with the Error Code "OAM Problem" [RFC7260] and the new Error Value
+   "Exit Loopback Failure".
+
+   After the loopback mode is cleared successfully, the ingress node MAY
+   remove the Lock Instruct using the mechanism defined in Section 3.1.
+   The ingress node MUST NOT request to exit lock mode if the LSP is
+
+
+
+Dong, et al.                 Standards Track                    [Page 5]
+
+RFC 7571             RSVP-TE Extensions for LI & LB            July 2015
+
+
+   still in loopback mode.  The egress node MUST ignore such a request
+   when the LSP is still in loopback mode.
+
+4.  IANA Considerations
+
+   IANA has assigned new values defined in this document and summarized
+   in this section.
+
+4.1.  Attribute Flags
+
+   IANA maintains a registry called "Resource Reservation Protocol-
+   Traffic Engineering (RSVP-TE) Parameters" with a sub-registry called
+   "Attribute Flags".
+
+   IANA has assigned a new bit flag as follows:
+
+    Bit |           | Attribute  | Attribute  |     |     |
+    No. | Name      | Flags Path | Flags Resv | RRO | ERO |  Reference
+   -----+-----------+------------+------------+-----+-----+-------------
+     13 | Loopback  |   Yes      |   No       | Yes | Yes |this document
+
+4.2.  RSVP Error Value Sub-Codes
+
+   IANA maintains a registry called "Resource Reservation Protocol
+   (RSVP) Parameters" with a sub-registry called "Error Codes and
+   Globally-Defined Error Value Sub-Codes".
+
+   IANA has assigned four new Error Value sub-codes for the "OAM
+   Problem" Error Code:
+
+      Value   |  Description                | Reference
+   -----------+-----------------------------+--------------
+        26    |  Lock Failure               | this document
+        27    |  Unlock Failure             | this document
+        28    |  Loopback Failure           | this document
+        29    |  Exit Loopback Failure      | this document
+
+4.3.  Allocation Rule for ERO Subobjects
+
+   IANA maintains a registry called "Resource Reservation Protocol
+   (RSVP) Parameters" with a sub-registry called "Class Names, Class
+   Numbers, and Class Types".
+
+   For Explicit Route Object, the allocation rule for subobject types in
+   the range 5-31 (0x05 - 0x1F) has been updated as:
+
+   5-31     Unassigned    (For explicit resource identification)
+
+
+
+
+Dong, et al.                 Standards Track                    [Page 6]
+
+RFC 7571             RSVP-TE Extensions for LI & LB            July 2015
+
+
+5.  Security Considerations
+
+   This document does not introduce any new security issues beyond those
+   identified in [RFC3209], [RFC3473], and [RFC7570].  For a more
+   comprehensive discussion of GMPLS security and attack mitigation
+   techniques, please see "Security Framework for MPLS and GMPLS
+   Networks" [RFC5920].
+
+   In addition, the reporting of the loopback status using the RRO may
+   reveal details about the node that the operator wishes to remain
+   confidential.  The privacy considerations as described in paragraph 3
+   of Section 5 of [RFC7570] also apply to this document.
+
+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>.
+
+   [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>.
+
+   [RFC3471]  Berger, L., Ed., "Generalized Multi-Protocol Label
+              Switching (GMPLS) Signaling Functional Description", RFC
+              3471, DOI 10.17487/RFC3471, January 2003,
+              <http://www.rfc-editor.org/info/rfc3471>.
+
+   [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>.
+
+   [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>.
+
+
+
+
+
+
+
+
+Dong, et al.                 Standards Track                    [Page 7]
+
+RFC 7571             RSVP-TE Extensions for LI & LB            July 2015
+
+
+   [RFC5860]  Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed.,
+              "Requirements for Operations, Administration, and
+              Maintenance (OAM) in MPLS Transport Networks", RFC 5860,
+              DOI 10.17487/RFC5860, May 2010,
+              <http://www.rfc-editor.org/info/rfc5860>.
+
+   [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>.
+
+   [RFC7570]  Margaria, C., Ed., Martinelli, G., Balls, S., and B.
+              Wright, "Label Switched Path (LSP) Attribute in the
+              Explicit Route Object (ERO)", RFC 7570,
+              DOI 10.17487/RFC7570, July 2015,
+              <http://www.rfc-editor.org/info/rfc7570>.
+
+6.2.  Informative References
+
+   [RFC5920]  Fang, L., Ed., "Security Framework for MPLS and GMPLS
+              Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,
+              <http://www.rfc-editor.org/info/rfc5920>.
+
+   [RFC6371]  Busi, I., Ed. and D. Allan, Ed., "Operations,
+              Administration, and Maintenance Framework for MPLS-Based
+              Transport Networks", RFC 6371, DOI 10.17487/RFC6371,
+              September 2011, <http://www.rfc-editor.org/info/rfc6371>.
+
+   [RFC6435]  Boutros, S., Ed., Sivabalan, S., Ed., Aggarwal, R., Ed.,
+              Vigoureux, M., Ed., and X. Dai, Ed., "MPLS Transport
+              Profile Lock Instruct and Loopback Functions", RFC 6435,
+              DOI 10.17487/RFC6435, November 2011,
+              <http://www.rfc-editor.org/info/rfc6435>.
+
+   [RFC7487]  Bellagamba, E., Takacs, A., Mirsky, G., Andersson, L.,
+              Skoldstrom, P., and D. Ward, "Configuration of Proactive
+              Operations, Administration, and Maintenance (OAM)
+              Functions for MPLS-Based Transport Networks Using RSVP-
+              TE", RFC 7487, DOI 10.17487/RFC7487, March 2015,
+              <http://www.rfc-editor.org/info/rfc7487>.
+
+
+
+
+
+
+
+
+
+
+
+Dong, et al.                 Standards Track                    [Page 8]
+
+RFC 7571             RSVP-TE Extensions for LI & LB            July 2015
+
+
+Acknowledgments
+
+   The authors would like to thank Greg Mirsky, Lou Berger, and
+   Francesco Fondelli for their comments and suggestions.
+
+Authors' Addresses
+
+   Jie Dong
+   Huawei Technologies
+   Huawei Campus, No.156 Beiqing Rd.
+   Beijing  100095
+   China
+
+   Email: jie.dong@huawei.com
+
+
+   Mach(Guoyi) Chen
+   Huawei Technologies
+   Huawei Campus, No.156 Beiqing Rd.
+   Beijing  100095
+   China
+
+   Email: mach.chen@huawei.com
+
+
+   Zhenqiang Li
+   China Mobile
+   Unit2, Dacheng Plaza, No. 28 Xuanwumenxi Ave.
+   Beijing  100053
+   China
+
+   Email: lizhenqiang@chinamobile.com
+
+
+   Daniele Ceccarelli
+   Ericsson
+   Via A. Negrone 1/A
+   Genova - Sestri Ponente
+   Italy
+
+   Email: daniele.ceccarelli@ericsson.com
+
+
+
+
+
+
+
+
+
+
+Dong, et al.                 Standards Track                    [Page 9]
+