doc: Add RFC documents

1 files changed, 563 insertions, 0 deletions

diff --git a/doc/rfc/rfc7876.txt b/doc/rfc/rfc7876.txt
new file mode 100644
index 0000000..8047cb2
--- /dev/null
+++ b/doc/rfc/rfc7876.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                         S. Bryant
+Request for Comments: 7876                                   Independent
+Category: Standards Track                                   S. Sivabalan
+ISSN: 2070-1721                                                  S. Soni
+                                                           Cisco Systems
+                                                               July 2016
+
+
+UDP Return Path for Packet Loss and Delay Measurement for MPLS Networks
+
+Abstract
+
+   RFC 6374 defines a protocol for Packet Loss and Delay Measurement for
+   MPLS networks (MPLS-PLDM).  This document specifies the procedures to
+   be used when sending and processing out-of-band MPLS performance
+   management Responses over an UDP/IP return path.
+
+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 7841.
+
+   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/rfc7876.
+
+Copyright Notice
+
+   Copyright (c) 2016 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.
+
+
+
+
+
+
+Bryant, et al.               Standards Track                    [Page 1]
+
+RFC 7876              UDP Return Path for MPLS-PLDM            July 2016
+
+
+Table of Contents
+
+   1. Introduction ....................................................3
+   2. Requirements Language ...........................................3
+   3. Solution Overview ...............................................3
+      3.1. UDP Return Object ..........................................4
+   4. Theory of Operation .............................................5
+      4.1. Sending an MPLS-PLDM Query .................................5
+      4.2. Receiving an MPLS-PLDM Query Request .......................5
+      4.3. Sending an MPLS-PLDM Response ..............................6
+      4.4. Receiving an MPLS-PLDM Response ............................7
+   5. Congestion Considerations .......................................7
+   6. Manageability Considerations ....................................8
+   7. Security Considerations .........................................8
+   8. IANA Considerations .............................................8
+   9. References ......................................................9
+      9.1. Normative References .......................................9
+      9.2. Informative References .....................................9
+   Acknowledgements ..................................................10
+   Authors' Addresses ................................................10
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bryant, et al.               Standards Track                    [Page 2]
+
+RFC 7876              UDP Return Path for MPLS-PLDM            July 2016
+
+
+1.  Introduction
+
+   This document describes how MPLS-PLDM [RFC6374] out-of-band Responses
+   can be delivered to the querier using UDP/IP.
+
+   The use of UDP may be required to support data-path management such
+   as passage through firewalls or to provide the necessary multiplexing
+   needed in bistatic operation where the querier and the collector are
+   not co-located and the collector is gathering the Response
+   information for a number of responders.  In a highly scaled system,
+   some MPLS-PLDM sessions may be off-loaded to a specific node within
+   the distributed system that comprises the Label Switching Router
+   (LSR) as a whole.  In such systems, the Response may arrive via any
+   interface in the LSR and needs to be forwarded internally to the
+   processor tasked with handling the particular MPLS-PLDM measurement.
+   Currently, the MPLS-PLDM protocol does not have any mechanism to
+   deliver the PLDM Response message to a particular node within a
+   multi-CPU LSR.
+
+   The procedure described in this specification describes how the
+   querier requests delivery of the MPLS-PLDM Response over IP to a
+   dynamic UDP port.  It makes no other changes to the protocol and thus
+   does not affect the case where the Response is delivered over an MPLS
+   Associated Channel [RFC5586].
+
+2.  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 [RFC2119].
+
+3.  Solution Overview
+
+   This document specifies that, unless configured otherwise, if a UDP
+   Return Object (URO) is present in an MPLS-PLDM Query, the responder
+   SHOULD use the IP address and UDP port in the URO to reply back to
+   the querier.  The querier MAY include multiple UROs in an MPLS-PLDM
+   Query indicating to the responder that an identical Response SHOULD
+   be sent to each address-port pair.  A responder MAY be designed or
+   configured to only transmit a single Response, in which case the
+   Response MUST be sent using the parameters specified in the first URO
+   in the Query packet that it is able to use (see Section 4.3).
+
+   The procedures defined in this document may be applied to both
+   unidirectional and bidirectional Label Switched Paths (LSPs).  In
+   this document, the term "bidirectional LSP" includes the co-routed
+   bidirectional LSP defined in [RFC3945] and the associated
+   bidirectional LSP that is constructed from a pair of unidirectional
+
+
+
+Bryant, et al.               Standards Track                    [Page 3]
+
+RFC 7876              UDP Return Path for MPLS-PLDM            July 2016
+
+
+   LSPs (one for each direction) that are associated with one another at
+   the LSP's ingress/egress points [RFC5654].  The mechanisms defined in
+   this document can apply to both IP/MPLS and to the MPLS Transport
+   Profile (MPLS-TP) [RFC5654] [RFC5921].
+
+3.1.  UDP Return Object
+
+   The format of the UDP Return Object (URO) is as follows:
+
+       0                   1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      | URO Type      | Length={6,18} |    UDP-Destination-Port       |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      ~                           Address                             ~
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The Type and Length fields are each 8 bits long.  The Length field
+   indicates the size in bytes of the remainder of the object (i.e., it
+   is the size of the address in bytes plus 2).  When the address is
+   IPv4, the Length field is thus 6; when the address is IPv6, the
+   Length field is thus 18.  The Length field therefore acts as both the
+   TLV parsing parameter and the address family type indicator.
+
+   The UDP Return Object Type (URO Type) has a value of 131.
+
+   The UDP-Destination-Port is a UDP destination port as specified in
+   [RFC768].
+
+   The Address is either an IPv4 or an IPv6 address.
+
+   The URO MUST NOT appear in a Response and MUST be ignored if it is
+   found to be present.
+
+   To prevent any ambiguity as to which address the responder needs to
+   reply to, an MPLS-PLDM Query message containing a URO MUST NOT
+   include an RFC 6374 Return Address TLV (TLV 1).  Additionally, the
+   method of constructing the return address from the Source Address TLV
+   (TLV 130) described in Section 3.5.2 of [RFC6374] MUST NOT be used to
+   construct a Response to a Query message that contains a URO.
+
+
+
+
+
+
+
+
+
+
+
+Bryant, et al.               Standards Track                    [Page 4]
+
+RFC 7876              UDP Return Path for MPLS-PLDM            July 2016
+
+
+4.  Theory of Operation
+
+   This document defines the UDP Return Object to enable the MPLS-PLDM
+   querier to specify the return path for the MPLS-PLDM reply using UDP/
+   IP encapsulation.
+
+   When the MPLS-PLDM Response is requested out-of-band by setting the
+   Control Code of the MPLS-PLDM Query to "Out-of-band Response
+   Requested", and the URO is present, the responder SHOULD send the
+   Response back to querier on the specified destination UDP port at the
+   specified destination IP address contained in the URO.
+
+   If the URO is expected but is not present in a Query message and an
+   MPLS-PLDM Response is requested out-of-band, the Query message MUST
+   NOT be processed further, and if possible, an "Error - Invalid
+   Message" ([RFC6374], Section 3.1) SHOULD be sent to the querier and
+   the operator notified via the management system (see Section 4.2 for
+   further details).
+
+4.1.  Sending an MPLS-PLDM Query
+
+   When sending an MPLS-PLDM Query message, in addition to the rules and
+   procedures defined in [RFC6374], the Control Code of the MPLS-PLDM
+   Query MUST be set to "Out-of-band Response Requested", and a URO MUST
+   be carried in the MPLS-PLDM Query message.
+
+   If the querier uses the UDP port to de-multiplex the Response for a
+   different measurement type, there MUST be a different UDP port for
+   each measurement type (delay, loss, and delay-loss combined).
+
+   An implementation MAY use multiple UDP ports for the same measurement
+   type to direct the Response to the correct management process in the
+   LSR.
+
+4.2.  Receiving an MPLS-PLDM Query Request
+
+   The processing of MPLS-PLDM Query messages as defined in [RFC6374]
+   applies in this document.  In addition, when an MPLS-PLDM Query
+   message is received, with the Control Code of the MPLS-PLDM Query set
+   to "Out-of-band Response Requested" with a URO present, then the
+   responder SHOULD use that IP address and UDP port to send an MPLS-
+   PLDM Response back to the querier.
+
+   If an out-of-band Response is requested and the URO is missing, the
+   Query SHOULD be dropped in the case of a unidirectional LSP.  If the
+   TLV is missing on a bidirectional LSP, the Control Code of the
+   Response message SHOULD set to 0x1C indicating "Error - Invalid
+   Message" ([RFC6374], Section 3.1), and the Response SHOULD be sent
+
+
+
+Bryant, et al.               Standards Track                    [Page 5]
+
+RFC 7876              UDP Return Path for MPLS-PLDM            July 2016
+
+
+   over the reverse LSP.  The receipt of such a malformed request SHOULD
+   be reported to the operator through the management system, with
+   normal precautions taken in respect to the prevention of overload of
+   the error-reporting system.
+
+4.3.  Sending an MPLS-PLDM Response
+
+   As specified in [RFC6374], the MPLS-PLDM Response can be sent either
+   over the reverse MPLS LSP for a bidirectional LSP or over an IP path.
+   It MUST NOT be sent other than in Response to an MPLS-PLDM Query
+   message.
+
+   When the requested return path is an IP forwarding path and this
+   method is in use, the destination IP address and UDP port are copied
+   from the URO.  The source IP address and the source UDP port of the
+   Response packet are left to the discretion of the responder, subject
+   to the normal management and security considerations.  If the querier
+   has included URO(s) for only one IP address family and a return path
+   of that type is not available, then the Query message MUST be
+   discarded, and the operator SHOULD be informed of the error through
+   the management system using the normal rate-limited approach.  If the
+   responder is configured to only respond with a single Response, and a
+   path using the IP address family in the first URO is not available,
+   the responder MAY search the UROs for the first URO specifying a
+   return address family for which it does have a path and use the
+   parameters in that URO to respond.  If the responder is designed or
+   configured not to search for a URO that it can respond to, then the
+   operator SHOULD be informed of the error through the management
+   system using the normal rate-limited approach.
+
+   The packet format for the MPLS-PLDM Response after the UDP header is
+   as specified in [RFC6374].  As shown in Figure 1, the Associated
+   Channel Header (ACH) [RFC5586] is not included.  The information
+   provided by the ACH is not needed since the correct binding between
+   the Query and Response messages is achieved through the UDP port and
+   the session identifier contained in the RFC 6374 message.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bryant, et al.               Standards Track                    [Page 6]
+
+RFC 7876              UDP Return Path for MPLS-PLDM            July 2016
+
+
+       +----------------------------------------------------------+
+       |  IP Header                                               |
+       .    Source Address = Responders IP Address                |
+       .    Destination Address = URO.Address                     |
+       .    Protocol = UDP                                        .
+       .                                                          .
+       +----------------------------------------------------------+
+       | UDP Header                                               |
+       .   Source Port = As chosen by Responder                   .
+       .   Destination Port = URO.UDP-Destination-Port            .
+       .                                                          .
+       +----------------------------------------------------------+
+       | Message as specified in RFC 6374                         |
+       .                                                          .
+       +----------------------------------------------------------+
+
+                     Figure 1: Response Packet Format
+
+   If the return path is an IP path, only one-way delay or one-way loss
+   measurement can be carried out.  In this case, timestamps 3 and 4
+   MUST be zero as specified in [RFC6374].
+
+4.4.  Receiving an MPLS-PLDM Response
+
+   If the Response was received over UDP/IP and an out-of-band Response
+   was expected, the Response message SHOULD be directed to the
+   appropriate measurement process as determined by the destination UDP
+   port and processed using the corresponding measurement type procedure
+   specified in [RFC6374].
+
+   If the Response was received over UDP/IP and an out-of-band Response
+   was not requested, that Response SHOULD be dropped, and the event
+   SHOULD be reported to the operator through the management system,
+   with normal precautions taken in respect to the prevention of
+   overload of the error-reporting system.
+
+5.  Congestion Considerations
+
+   This protocol MUST be run in accordance with the guidance provided in
+   [RFC5405].  As advised in Section 3.1.2 of RFC 5405, operators that
+   wish to run this protocol at rates in excess of one packet per three
+   seconds need to ensure that the MPLS path being monitored and any IP
+   path that may be used to carry the Response are provisioned such that
+   there is a negligible chance of this protocol causing congestion.
+   Additionally, if a significant number of Response packets are lost,
+   the querier MUST reduce the sending rate to a point where there is a
+   negligible chance that this protocol is contributing to network
+   congestion.  The operator should also take precautions that Response
+
+
+
+Bryant, et al.               Standards Track                    [Page 7]
+
+RFC 7876              UDP Return Path for MPLS-PLDM            July 2016
+
+
+   packets do not leak out of the network domain being used and cause
+   congestion elsewhere.  If a default IP address is configured by the
+   equipment vendor, this MUST be an address known to contain the
+   Response packet within the responder.  A responder receiving a Query
+   specifying this as a return address, and not being configured to
+   expect such a return address, SHOULD notify the operator in a
+   suitably rate-limited manner.
+
+6.  Manageability Considerations
+
+   The manageability considerations described in Section 7 of [RFC6374]
+   are applicable to this specification.  Additional manageability
+   considerations are noted within the elements of procedure in this
+   document.
+
+   Nothing in this document precludes the use of a configured UDP/IP
+   return path in a deployment in which configuration is preferred to
+   signaling.  In these circumstances, the URO MAY be omitted from the
+   MPLS-PLDM messages.
+
+7.  Security Considerations
+
+   The MPLS-PLDM system is not intended to be deployed on the public
+   Internet.  It is intended for deployment in well-managed private and
+   service provider networks.  The security considerations described in
+   Section 8 of [RFC6374] are applicable to this specification, and
+   particular attention should be paid to the last two paragraphs.
+   Cryptographic measures may be enhanced by the correct configuration
+   of access-control lists and firewalls.
+
+   To prevent the use of this protocol as a reflection attack vector,
+   the operator should ensure that the IP address in the URO addresses a
+   system that is expecting to act as a receiver of PLDM Responses.
+
+   There is no additional exposure of information to pervasive
+   monitoring systems observing LSPs that are being monitored.
+
+8.  IANA Considerations
+
+   IANA has assigned a new optional TLV type from the "MPLS Loss/Delay
+   Measurement TLV Object" registry contained within the "Generic
+   Associated Channel (G-ACh) Parameters" registry set:
+
+      Code         Description        Reference
+       131         UDP Return         [RFC7876]
+
+
+
+
+
+
+Bryant, et al.               Standards Track                    [Page 8]
+
+RFC 7876              UDP Return Path for MPLS-PLDM            July 2016
+
+
+9.  References
+
+9.1.  Normative References
+
+   [RFC768]   Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+              DOI 10.17487/RFC0768, August 1980,
+              <http://www.rfc-editor.org/info/rfc768>.
+
+   [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>.
+
+   [RFC3945]  Mannie, E., Ed., "Generalized Multi-Protocol Label
+              Switching (GMPLS) Architecture", RFC 3945,
+              DOI 10.17487/RFC3945, October 2004,
+              <http://www.rfc-editor.org/info/rfc3945>.
+
+   [RFC5405]  Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines
+              for Application Designers", BCP 145, RFC 5405,
+              DOI 10.17487/RFC5405, November 2008,
+              <http://www.rfc-editor.org/info/rfc5405>.
+
+   [RFC5586]  Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,
+              "MPLS Generic Associated Channel", RFC 5586,
+              DOI 10.17487/RFC5586, June 2009,
+              <http://www.rfc-editor.org/info/rfc5586>.
+
+   [RFC5654]  Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed.,
+              Sprecher, N., and S. Ueno, "Requirements of an MPLS
+              Transport Profile", RFC 5654, DOI 10.17487/RFC5654,
+              September 2009, <http://www.rfc-editor.org/info/rfc5654>.
+
+   [RFC6374]  Frost, D. and S. Bryant, "Packet Loss and Delay
+              Measurement for MPLS Networks", RFC 6374,
+              DOI 10.17487/RFC6374, September 2011,
+              <http://www.rfc-editor.org/info/rfc6374>.
+
+9.2.  Informative References
+
+   [RFC5921]  Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau,
+              L., and L. Berger, "A Framework for MPLS in Transport
+              Networks", RFC 5921, DOI 10.17487/RFC5921, July 2010,
+              <http://www.rfc-editor.org/info/rfc5921>.
+
+
+
+
+
+
+
+Bryant, et al.               Standards Track                    [Page 9]
+
+RFC 7876              UDP Return Path for MPLS-PLDM            July 2016
+
+
+Acknowledgements
+
+   We acknowledge the contributions of Joseph Chin and Rakesh Gandhi,
+   both with Cisco Systems.  We thank Loa Andersson, Eric Osborne,
+   Mustapha Aissaoui, Jeffrey Zhang, and Ross Callon for their review
+   comments.
+
+   We thank all who have reviewed this text and provided feedback.
+
+Authors' Addresses
+
+   Stewart Bryant
+   Independent
+
+   Email: stewart.bryant@gmail.com
+
+
+   Siva Sivabalan
+   Cisco Systems
+
+   Email: msiva@cisco.com
+
+
+   Sagar Soni
+   Cisco Systems
+
+   Email: sagsoni@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bryant, et al.               Standards Track                   [Page 10]
+