doc: Add RFC documents

1 files changed, 1291 insertions, 0 deletions

diff --git a/doc/rfc/rfc6424.txt b/doc/rfc/rfc6424.txt
new file mode 100644
index 0000000..28af3a2
--- /dev/null
+++ b/doc/rfc/rfc6424.txt
@@ -0,0 +1,1291 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                        N. Bahadur
+Request for Comments: 6424                                   K. Kompella
+Updates: 4379                                     Juniper Networks, Inc.
+Category: Standards Track                                     G. Swallow
+ISSN: 2070-1721                                            Cisco Systems
+                                                           November 2011
+
+
+      Mechanism for Performing Label Switched Path Ping (LSP Ping)
+                           over MPLS Tunnels
+
+Abstract
+
+   This document describes methods for performing LSP ping (specified in
+   RFC 4379) traceroute over MPLS tunnels and for traceroute of stitched
+   MPLS Label Switched Paths (LSPs).  The techniques outlined in RFC
+   4379 are insufficient to perform traceroute Forwarding Equivalency
+   Class (FEC) validation and path discovery for an LSP that goes over
+   other MPLS tunnels or for a stitched LSP.  This document deprecates
+   the Downstream Mapping TLV (defined in RFC 4379) in favor of a new
+   TLV that, along with other procedures outlined in this document, can
+   be used to trace such LSPs.
+
+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/rfc6424.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bahadur, et al.              Standards Track                    [Page 1]
+
+RFC 6424               LSP Ping over MPLS Tunnels          November 2011
+
+
+Copyright Notice
+
+   Copyright (c) 2011 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.
+
+   This document may contain material from IETF Documents or IETF
+   Contributions published or made publicly available before November
+   10, 2008.  The person(s) controlling the copyright in some of this
+   material may not have granted the IETF Trust the right to allow
+   modifications of such material outside the IETF Standards Process.
+   Without obtaining an adequate license from the person(s) controlling
+   the copyright in such materials, this document may not be modified
+   outside the IETF Standards Process, and derivative works of it may
+   not be created outside the IETF Standards Process, except to format
+   it for publication as an RFC or to translate it into languages other
+   than English.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bahadur, et al.              Standards Track                    [Page 2]
+
+RFC 6424               LSP Ping over MPLS Tunnels          November 2011
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
+     1.1.  Conventions Used in This Document  . . . . . . . . . . . .  4
+   2.  Motivation . . . . . . . . . . . . . . . . . . . . . . . . . .  4
+   3.  Packet Format  . . . . . . . . . . . . . . . . . . . . . . . .  5
+     3.1.  Summary of Changes . . . . . . . . . . . . . . . . . . . .  5
+     3.2.  New Return Codes . . . . . . . . . . . . . . . . . . . . .  6
+       3.2.1.  Return Code per Downstream . . . . . . . . . . . . . .  6
+       3.2.2.  Return Code for Stitched LSPs  . . . . . . . . . . . .  6
+     3.3.  Downstream Detailed Mapping TLV  . . . . . . . . . . . . .  7
+       3.3.1.  Sub-TLVs . . . . . . . . . . . . . . . . . . . . . . .  9
+         3.3.1.1.  Multipath Data Sub-TLV . . . . . . . . . . . . . .  9
+     3.4.  Deprecation of Downstream Mapping TLV  . . . . . . . . . . 13
+   4.  Performing MPLS Traceroute on Tunnels  . . . . . . . . . . . . 13
+     4.1.  Transit Node Procedure . . . . . . . . . . . . . . . . . . 13
+       4.1.1.  Addition of a New Tunnel . . . . . . . . . . . . . . . 13
+       4.1.2.  Transition between Tunnels . . . . . . . . . . . . . . 14
+       4.1.3.  Modification to FEC Validation Procedure on Transit  . 16
+     4.2.  Modification to FEC Validation Procedure on Egress . . . . 16
+     4.3.  Ingress Node Procedure . . . . . . . . . . . . . . . . . . 17
+       4.3.1.  Processing Downstream Detailed Mapping TLV . . . . . . 17
+         4.3.1.1.  Stack Change Sub-TLV Not Present . . . . . . . . . 17
+         4.3.1.2.  Stack Change Sub-TLV(s) Present  . . . . . . . . . 17
+       4.3.2.  Modifications to Handling a Return Code 3 Reply. . . . 19
+       4.3.3.  Handling of New Return Codes . . . . . . . . . . . . . 19
+     4.4.  Handling Deprecated Downstream Mapping TLV . . . . . . . . 20
+   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 20
+   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 21
+   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
+   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
+     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 22
+     8.2.  Informative References . . . . . . . . . . . . . . . . . . 22
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bahadur, et al.              Standards Track                    [Page 3]
+
+RFC 6424               LSP Ping over MPLS Tunnels          November 2011
+
+
+1.  Introduction
+
+   This documents describes methods for performing LSP ping (specified
+   in [RFC4379]) traceroute over MPLS tunnels.  The techniques in
+   [RFC4379] outline a traceroute mechanism that includes Forwarding
+   Equivalency Class (FEC) validation and Equal Cost Multi-Path (ECMP)
+   path discovery.  Those mechanisms are insufficient and do not provide
+   details when the FEC being traced traverses one or more MPLS tunnels
+   and when Label Switched Path (LSP) stitching [RFC5150] is in use.
+   This document deprecates the Downstream Mapping TLV [RFC4379],
+   introducing instead a new TLV that is more extensible and that
+   enables retrieval of detailed information.  Using the new TLV format
+   along with the existing definitions of [RFC4379], this document
+   describes procedures by which a traceroute request can correctly
+   traverse MPLS tunnels with proper FEC and label validations.
+
+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.  Motivation
+
+   An LSP ping traceroute may cross multiple MPLS tunnels en route to
+   the destination.  Let us consider a simple case.
+
+   A          B          C           D           E
+   o -------- o -------- o --------- o --------- o
+     \_____/  | \______/   \______/  | \______/
+       LDP    |   RSVP       RSVP    |    LDP
+              |                      |
+               \____________________/
+                        LDP
+
+                      Figure 1: LDP over RSVP Tunnel
+
+   When a traceroute is initiated from router A, router B returns
+   downstream mapping information for node C in the MPLS echo reply.
+   The next MPLS echo request reaches router C with an LDP FEC.  Node C
+   is a pure RSVP node and does not run LDP.  Node C will receive the
+   MPLS echo request with two labels but only one FEC in the Target FEC
+   stack.  Consequently, node C will be unable to perform a complete FEC
+   validation.  It will let the trace continue by just providing next-
+   hop information based on the incoming label, and by looking up the
+   forwarding state associated with that label.  However, ignoring FEC
+   validation defeats the purpose of control-plane validations.  The
+
+
+
+
+Bahadur, et al.              Standards Track                    [Page 4]
+
+RFC 6424               LSP Ping over MPLS Tunnels          November 2011
+
+
+   MPLS echo request should contain sufficient information to allow node
+   C to perform FEC validations to catch any misrouted echo requests.
+
+   The above problem can be extended for a generic case of hierarchical
+   tunnels or stitched tunnels (e.g., B-C can be a separate RSVP tunnel
+   and C-D can be a separate RSVP tunnel).  The problem of FEC
+   validation for tunnels can be solved if the transit routers (router B
+   in the above example) provide some information to the ingress
+   regarding the start of a new tunnel.
+
+   Stitched LSPs involve two or more LSP segments stitched together.
+   The LSP segments can be signaled using the same or different
+   signaling protocols.  In order to perform an end-to-end trace of a
+   stitched LSP, the ingress needs to know FEC information regarding
+   each of the stitched LSP segments.  For example, consider the figure
+   below.
+
+   A          B          C           D          E         F
+   o -------- o -------- o --------- o -------- o ------- o
+     \_____/    \______/   \______/    \______/  \_______/
+       LDP        LDP         BGP         RSVP      RSVP
+
+                          Figure 2: Stitched LSP
+
+   Consider ingress (A) tracing end-to-end stitched LSP A--F.  When an
+   MPLS echo request reaches router C, there is a FEC stack change
+   happening at router C.  With current LSP ping [RFC4379] mechanisms,
+   there is no way to convey this information to A.  Consequently, when
+   the next echo request reaches router D, router D will know nothing
+   about the LDP FEC that A is trying to trace.
+
+   Thus, the procedures defined in [RFC4379] do not make it possible for
+   the ingress node to:
+
+   1.  Know that tunneling has occurred.
+
+   2.  Trace the path of the tunnel.
+
+   3.  Trace the path of stitched LSPs.
+
+3.  Packet Format
+
+3.1.  Summary of Changes
+
+   In many cases, there is a need to associate additional data in the
+   MPLS echo reply.  In most cases, the additional data needs to be
+   associated on a per-downstream-neighbor basis.  Currently, the MPLS
+   echo reply contains one Downstream Mapping TLV (DSMAP) per downstream
+
+
+
+Bahadur, et al.              Standards Track                    [Page 5]
+
+RFC 6424               LSP Ping over MPLS Tunnels          November 2011
+
+
+   neighbor.  However, the DSMAP format is not extensible; hence, it is
+   not possible to associate more information with a downstream
+   neighbor.  This document defines a new extensible format for the
+   DSMAP and provides mechanisms for solving the tunneled LSP ping
+   problem using the new format.  In summary, this document makes the
+   following TLV changes:
+
+   o  Addition of new Downstream Detailed Mapping TLV (DDMAP).
+
+   o  Deprecation of existing Downstream Mapping TLV (DSMAP).
+
+   o  Addition of Downstream FEC stack change sub-TLV to DDMAP.
+
+3.2.  New Return Codes
+
+3.2.1.  Return Code per Downstream
+
+   A new Return Code is being defined "See DDM TLV for Return Code and
+   Return Subcode" (Section 6.3) to indicate that the Return Code is per
+   Downstream Detailed Mapping TLV (Section 3.3).  This Return Code MUST
+   be used only in the message header and MUST be set only in the MPLS
+   echo reply message.  If the Return Code is set in the MPLS echo
+   request message, then it MUST be ignored.  When this Return Code is
+   set, each Downstream Detailed Mapping TLV MUST have an appropriate
+   Return Code and Return Subcode.  This Return Code MUST be used when
+   there are multiple downstreams for a given node (such as Point to
+   Multipoint (P2MP) or Equal Cost Multi-Path (ECMP)), and the node
+   needs to return a Return Code/Return Subcode for each downstream.
+   This Return Code MAY be used even when there is only one downstream
+   for a given node.
+
+3.2.2.  Return Code for Stitched LSPs
+
+   When a traceroute is being performed on stitched LSPs
+   (Section 4.1.2), the stitching point SHOULD indicate the stitching
+   action to the node performing the trace.  This is done by setting the
+   Return Code to "Label switched with FEC change" (Section 6.3).  If a
+   node is performing FEC hiding, then it MAY choose to set the Return
+   Code to a value (specified in [RFC4379]) other than "Label switched
+   with FEC change".  The Return Code "Label switched with FEC change"
+   MUST NOT be used if no FEC stack sub-TLV (Section 3.3.1.3) is present
+   in the Downstream Detailed Mapping TLV(s).  This new Return Code MAY
+   be used for hierarchical LSPs (for indicating the start or end of an
+   outer LSP).
+
+
+
+
+
+
+
+Bahadur, et al.              Standards Track                    [Page 6]
+
+RFC 6424               LSP Ping over MPLS Tunnels          November 2011
+
+
+3.3.  Downstream Detailed Mapping TLV
+
+        Type #   Value Field
+        ------   ------------
+
+        20       Downstream Detailed Mapping
+
+   The Downstream Detailed Mapping object is a TLV that MAY be included
+   in an MPLS echo request message.  Only one Downstream Detailed
+   Mapping object may appear in an echo request.  The presence of a
+   Downstream Detailed Mapping object is a request that Downstream
+   Detailed Mapping objects be included in the MPLS echo reply.  If the
+   replying router is the destination (Label Edge Router) of the FEC,
+   then a Downstream Detailed Mapping TLV SHOULD NOT be included in the
+   MPLS echo reply.  Otherwise, the replying router SHOULD include a
+   Downstream Detailed Mapping object for each interface over which this
+   FEC could be forwarded.
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |               MTU             | Address Type  |    DS Flags   |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |               Downstream Address (4 or 16 octets)             |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |         Downstream Interface Address (4 or 16 octets)         |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |  Return Code  | Return Subcode|        Sub-tlv Length         |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      .                                                               .
+      .                      List of Sub-TLVs                         .
+      .                                                               .
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                 Figure 3: Downstream Detailed Mapping TLV
+
+   The Downstream Detailed Mapping TLV format is derived from the
+   Downstream Mapping TLV format.  The key change is that variable
+   length and optional fields have been converted into sub-TLVs.  The
+   fields have the same use and meaning as in [RFC4379].  A summary of
+   the fields taken from the Downstream Mapping TLV is as below:
+
+   Maximum Transmission Unit (MTU)
+
+      The MTU is the size in octets of the largest MPLS frame (including
+      label stack) that fits on the interface to the Downstream Label
+      Switching Router (LSR).
+
+
+
+
+Bahadur, et al.              Standards Track                    [Page 7]
+
+RFC 6424               LSP Ping over MPLS Tunnels          November 2011
+
+
+   Address Type
+
+      The Address Type indicates if the interface is numbered or
+      unnumbered.  It also determines the length of the Downstream IP
+      Address and Downstream Interface fields.
+
+   DS Flags
+
+      The DS Flags field is a bit vector of various flags.
+
+   Downstream Address and Downstream Interface Address
+
+      IPv4 addresses and interface indices are encoded in 4 octets; IPv6
+      addresses are encoded in 16 octets.  For details regarding setting
+      the address value, refer to [RFC4379].
+
+   The newly added sub-TLVs and their fields are as described below.
+
+   Return Code
+
+      The Return Code is set to zero by the sender.  The receiver can
+      set it to one of the values specified in the "Multi-Protocol Label
+      Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters"
+      registry, "Return Codes" sub-registry.
+
+      If the receiver sets a non-zero value of the Return Code field in
+      the Downstream Detailed Mapping TLV, then the receiver MUST also
+      set the Return Code field in the echo reply header to "See DDM TLV
+      for Return Code and Return Subcode" (Section 6.3).  An exception
+      to this is if the receiver is a bud node [RFC4461] and is replying
+      as both an egress and a transit node with a Return Code of 3
+      ("Replying router is an egress for the FEC at stack-depth <RSC>")
+      in the echo reply header.
+
+      If the Return Code of the echo reply message is not set to either
+      "See DDM TLV for Return Code and Return Subcode" (Section 6.3) or
+      "Replying router is an egress for the FEC at stack-depth <RSC>",
+      then the Return Code specified in the Downstream Detailed Mapping
+      TLV MUST be ignored.
+
+   Return Subcode
+
+      The Return Subcode is set to zero by the sender.  The receiver can
+      set it to one of the values specified in the "Multi-Protocol Label
+      Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters"
+      registry, "Return Codes" sub-registry.  This field is filled in
+      with the stack-depth for those codes that specify the stack-depth.
+      For all other codes, the Return Subcode MUST be set to zero.
+
+
+
+Bahadur, et al.              Standards Track                    [Page 8]
+
+RFC 6424               LSP Ping over MPLS Tunnels          November 2011
+
+
+      If the Return Code of the echo reply message is not set to either
+      "See DDM TLV for Return Code and Return Subcode" (Section 6.3) or
+      "Replying router is an egress for the FEC at stack-depth <RSC>",
+      then the Return Subcode specified in the Downstream Detailed
+      Mapping TLV MUST be ignored.
+
+   Sub-tlv Length
+
+      Total length in bytes of the sub-TLVs associated with this TLV.
+
+3.3.1.  Sub-TLVs
+
+   This section defines the sub-TLVs that MAY be included as part of the
+   Downstream Detailed Mapping TLV.
+
+        Sub-Type    Value Field
+        ---------   ------------
+          1         Multipath data
+          2         Label stack
+          3         FEC stack change
+
+3.3.1.1.  Multipath Data Sub-TLV
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |Multipath Type |       Multipath Length        |Reserved (MBZ) |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   |                  (Multipath Information)                      |
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                        Figure 4: Multipath Sub-TLV
+
+   The multipath data sub-TLV includes Multipath Information.  The sub-
+   TLV fields and their usage is as defined in [RFC4379].  A brief
+   summary of the fields is as below:
+
+   Multipath Type
+
+      The type of the encoding for the Multipath Information.
+
+   Multipath Length
+
+      The length in octets of the Multipath Information.
+
+
+
+
+
+Bahadur, et al.              Standards Track                    [Page 9]
+
+RFC 6424               LSP Ping over MPLS Tunnels          November 2011
+
+
+   MBZ
+
+      MUST be set to zero when sending; MUST be ignored on receipt.
+
+   Multipath Information
+
+      Encoded multipath data, according to the Multipath Type.
+
+3.3.1.2.  Label Stack Sub-TLV
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |               Downstream Label                |    Protocol   |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   .                                                               .
+   .                                                               .
+   .                                                               .
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |               Downstream Label                |    Protocol   |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                       Figure 5: Label Stack Sub-TLV
+
+   The Label stack sub-TLV contains the set of labels in the label stack
+   as it would have appeared if this router were forwarding the packet
+   through this interface.  Any Implicit Null labels are explicitly
+   included.  The number of label/protocol pairs present in the sub-TLV
+   is determined based on the sub-TLV data length.  The label format and
+   protocol type are as defined in [RFC4379].  When the Downstream
+   Detailed Mapping TLV is sent in the echo reply, this sub-TLV MUST be
+   included.
+
+   Downstream Label
+
+      A Downstream label is 24 bits, in the same format as an MPLS label
+      minus the Time to Live (TTL) field, i.e., the MSBit of the label
+      is bit 0, the LSBit is bit 19, the Traffic Class (TC) field
+      [RFC5462] is bits 20-22, and S is bit 23.  The replying router
+      SHOULD fill in the TC field and S bit; the LSR receiving the echo
+      reply MAY choose to ignore these.
+
+   Protocol
+
+      This specifies the label distribution protocol for the Downstream
+      label.
+
+
+
+
+
+Bahadur, et al.              Standards Track                   [Page 10]
+
+RFC 6424               LSP Ping over MPLS Tunnels          November 2011
+
+
+3.3.1.3.  FEC Stack Change Sub-TLV
+
+   A router MUST include the FEC stack change sub-TLV when the
+   downstream node in the echo reply has a different FEC Stack than the
+   FEC Stack received in the echo request.  One or more FEC stack change
+   sub-TLVs MAY be present in the Downstream Detailed Mapping TLV.  The
+   format is as below.
+
+   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 2
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |Operation Type | Address Type  | FEC-tlv length|  Reserved     |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |           Remote Peer Address (0, 4 or 16 octets)             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   .                                                               .
+   .                         FEC TLV                               .
+   .                                                               .
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                    Figure 6: FEC Stack Change Sub-TLV
+
+   Operation Type
+
+      The operation type specifies the action associated with the FEC
+      stack change.  The following operation types are defined:
+
+
+        Type #     Operation
+        ------     ---------
+        1          Push
+        2          Pop
+
+   Address Type
+
+      The Address Type indicates the remote peer's address type.  The
+      Address Type is set to one of the following values.  The length of
+      the peer address is determined based on the address type.  The
+      address type MAY be different from the address type included in
+      the Downstream Detailed Mapping TLV.  This can happen when the LSP
+      goes over a tunnel of a different address family.  The address
+      type MAY be set to Unspecified if the peer address is either
+      unavailable or the transit router does not wish to provide it for
+      security or administrative reasons.
+
+
+
+
+
+
+
+Bahadur, et al.              Standards Track                   [Page 11]
+
+RFC 6424               LSP Ping over MPLS Tunnels          November 2011
+
+
+        Type #   Address Type   Address length
+        ------   ------------   --------------
+
+        0        Unspecified    0
+        1        IPv4           4
+        2        IPv6           16
+
+   FEC TLV Length
+
+      Length in bytes of the FEC TLV.
+
+   Reserved
+
+      This field is reserved for future use and MUST be set to zero.
+
+   Remote Peer Address
+
+      The remote peer address specifies the remote peer that is the
+      next-hop for the FEC being currently traced.  For example, in the
+      LDP over RSVP case in Figure 1, router B would respond back with
+      the address of router D as the remote peer address for the LDP FEC
+      being traced.  This allows the ingress node to provide information
+      regarding FEC peers.  If the operation type is PUSH, the remote
+      peer address is the address of the peer from which the FEC being
+      pushed was learned.  If the operation type is POP, the remote peer
+      address MAY be set to Unspecified.
+
+      For upstream-assigned labels [RFC5331], an operation type of POP
+      will have a remote peer address (the upstream node that assigned
+      the label) and this SHOULD be included in the FEC stack change
+      sub-TLV.  The remote peer address MAY be set to Unspecified if the
+      address needs to be hidden.
+
+   FEC TLV
+
+      The FEC TLV is present only when the FEC-tlv length field is non-
+      zero.  The FEC TLV specifies the FEC associated with the FEC stack
+      change operation.  This TLV MAY be included when the operation
+      type is POP.  It MUST be included when the operation type is PUSH.
+      The FEC TLV contains exactly one FEC from the list of FECs
+      specified in [RFC4379].  A Nil FEC MAY be associated with a PUSH
+      operation if the responding router wishes to hide the details of
+      the FEC being pushed.
+
+
+
+
+
+
+
+
+Bahadur, et al.              Standards Track                   [Page 12]
+
+RFC 6424               LSP Ping over MPLS Tunnels          November 2011
+
+
+   FEC stack change sub-TLV operation rules are as follows:
+
+   a.  A FEC stack change sub-TLV containing a PUSH operation MUST NOT
+       be followed by a FEC stack change sub-TLV containing a POP
+       operation.
+
+   b.  One or more POP operations MAY be followed by one or more PUSH
+       operations.
+
+   c.  One FEC stack change sub-TLV MUST be included per FEC stack
+       change.  For example, if 2 labels are going to be pushed, then
+       one FEC stack change sub-TLV MUST be included for each FEC.
+
+   d.  A FEC splice operation (an operation where one FEC ends and
+       another FEC starts, see Figure 7) MUST be performed by including
+       a POP type FEC stack change sub-TLV followed by a PUSH type FEC
+       stack change sub-TLV.
+
+   e.  A Downstream detailed mapping TLV containing only one FEC stack
+       change sub-TLV with Pop operation is equivalent to IS_EGRESS
+       (Return Code 3, [RFC4379]) for the outermost FEC in the FEC
+       stack.  The ingress router performing the MPLS traceroute MUST
+       treat such a case as an IS_EGRESS for the outermost FEC.
+
+3.4.  Deprecation of Downstream Mapping TLV
+
+   This document deprecates the Downstream Mapping TLV.  LSP ping
+   procedures should now use the Downstream Detailed Mapping TLV.
+   Detailed procedures regarding interoperability between the deprecated
+   TLV and the new TLV are specified in Section 4.4.
+
+4.  Performing MPLS Traceroute on Tunnels
+
+   This section describes the procedures to be followed by an LSP
+   ingress node and LSP transit nodes when performing MPLS traceroute
+   over MPLS tunnels.
+
+4.1.  Transit Node Procedure
+
+4.1.1.  Addition of a New Tunnel
+
+   A transit node (Figure 1) knows when the FEC being traced is going to
+   enter a tunnel at that node.  Thus, it knows about the new outer FEC.
+   All transit nodes that are the origination point of a new tunnel
+   SHOULD add the FEC stack change sub-TLV (Section 3.3.1.3) to the
+   Downstream Detailed Mapping TLV (Figure 3) in the echo reply.  The
+   transit node SHOULD add one FEC stack change sub-TLV of operation
+   type PUSH, per new tunnel being originated at the transit node.
+
+
+
+Bahadur, et al.              Standards Track                   [Page 13]
+
+RFC 6424               LSP Ping over MPLS Tunnels          November 2011
+
+
+   A transit node that sends a Downstream FEC stack change sub-TLV in
+   the echo reply SHOULD fill the address of the remote peer; which is
+   the peer of the current LSP being traced.  If the transit node does
+   not know the address of the remote peer, it MUST set the address type
+   to Unspecified.
+
+   The Label stack sub-TLV MUST contain one additional label per FEC
+   being PUSHed.  The label MUST be encoded as per Figure 5.  The label
+   value MUST be the value used to switch the data traffic.  If the
+   tunnel is a transparent pipe to the node, i.e. the data-plane trace
+   will not expire in the middle of the new tunnel, then a FEC stack
+   change sub-TLV SHOULD NOT be added and the Label stack sub-TLV SHOULD
+   NOT contain a label corresponding to the hidden tunnel.
+
+   If the transit node wishes to hide the nature of the tunnel from the
+   ingress of the echo request, then it MAY not want to send details
+   about the new tunnel FEC to the ingress.  In such a case, the transit
+   node SHOULD use the Nil FEC.  The echo reply would then contain a FEC
+   stack change sub-TLV with operation type PUSH and a Nil FEC.  The
+   value of the label in the Nil FEC MUST be set to zero.  The remote
+   peer address type MUST be set to Unspecified.  The transit node
+   SHOULD add one FEC stack change sub-TLV of operation type PUSH, per
+   new tunnel being originated at the transit node.  The Label stack
+   sub-TLV MUST contain one additional label per FEC being PUSHed.  The
+   label value MUST be the value used to switch the data traffic.
+
+4.1.2.  Transition between Tunnels
+
+   A          B          C           D          E         F
+   o -------- o -------- o --------- o -------- o ------- o
+     \_____/    \______/   \______/    \______/  \_______/
+       LDP        LDP         BGP         RSVP      RSVP
+
+                          Figure 7: Stitched LSPs
+
+   In the above figure, we have three separate LSP segments stitched at
+   C and D.  Node C SHOULD include two FEC stack change sub-TLVs.  One
+   with a POP operation for the LDP FEC and one with the PUSH operation
+   for the BGP FEC.  Similarly, node D SHOULD include two FEC stack
+   change sub-TLVs, one with a POP operation for the BGP FEC and one
+   with a PUSH operation for the RSVP FEC.  Nodes C and D SHOULD set the
+   Return Code to "Label switched with FEC change" (Section 6.3) to
+   indicate change in FEC being traced.
+
+   If node C wishes to perform FEC hiding, it SHOULD respond back with
+   two FEC stack change sub-TLVs, one POP followed by one PUSH.  The POP
+   operation MAY either exclude the FEC TLV (by setting the FEC TLV
+   length to 0) or set the FEC TLV to contain the LDP FEC.  The PUSH
+
+
+
+Bahadur, et al.              Standards Track                   [Page 14]
+
+RFC 6424               LSP Ping over MPLS Tunnels          November 2011
+
+
+   operation SHOULD have the FEC TLV containing the Nil FEC.  The Return
+   Code SHOULD be set to "Label switched with FEC change".
+
+   If node C performs FEC hiding and node D also performs FEC hiding,
+   then node D MAY choose to not send any FEC stack change sub-TLVs in
+   the echo reply since the number of labels has not changed (for the
+   downstream of node D) and the FEC type also has not changed (Nil
+   FEC).  In such a case, node D MUST NOT set the Return Code to "Label
+   switched with FEC change".  If node D performs FEC hiding, then node
+   F will respond as IS_EGRESS for the Nil FEC.  The ingress (node A)
+   will know that IS_EGRESS corresponds to the end-to-end LSP.
+
+   A          B          C           D           E           F
+   o -------- o -------- o --------- o --------- o --------- o
+     \_____/  |\____________________/            |\_______/
+       LDP    |\       RSVP-A                    |    LDP
+              | \_______________________________/|
+              |       RSVP-B                     |
+               \________________________________/
+                               LDP
+
+                        Figure 8: Hierarchical LSPs
+
+   In the above figure, we have an end-to-end LDP LSP between nodes A
+   and F.  The LDP LSP goes over RSVP LSP RSVP-B.  LSP RSVP-B itself
+   goes over another RSVP LSP RSVP-A.  When node A initiates a
+   traceroute for the end-to-end LDP LSP, then following sequence of FEC
+   stack change sub-TLVs will be performed
+
+   Node B:
+
+   Respond with two FEC stack change sub-TLVs: PUSH RSVP-B, PUSH RSVP-A.
+
+   Node D:
+
+   Respond with Return Code 3 when RSVP-A is the top of FEC stack.  When
+   the echo request contains RSVP-B as top of stack, respond with
+   Downstream information for node E and an appropriate Return Code.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bahadur, et al.              Standards Track                   [Page 15]
+
+RFC 6424               LSP Ping over MPLS Tunnels          November 2011
+
+
+   If node B is performing tunnel hiding, then:
+
+   Node B:
+
+   Respond with two FEC stack change sub-TLVs: PUSH Nil FEC, PUSH Nil
+   FEC.
+
+   Node D:
+
+   If D determines that the Nil FEC corresponds to RSVP-A, which
+   terminates at D, then it SHOULD respond with Return Code 3.  D can
+   also respond with FEC stack change sub-TLV: POP (since D knows that
+   number of labels towards next-hop is decreasing).  Both responses
+   would be valid.
+
+   A          B          C        D        E       F       G
+   o -------- o -------- o ------ o ------ o ----- o ----- o
+        LDP       LDP        BGP   \  RSVP    RSVP /  LDP
+                                    \_____________/
+                                         LDP
+
+                   Figure 9: Stitched Hierarchical LSPs
+
+   In the above case, node D will send three FEC stack change sub-TLVs.
+   One POP (for the BGP FEC) followed by two PUSHes (one for LDP and one
+   for RSVP).  Nodes C and D SHOULD set the Return Code to "Label
+   switched with FEC change" (Section 6.3) to indicate change in FEC
+   being traced.
+
+4.1.3.  Modification to FEC Validation Procedure on Transit
+
+   Section 4.4 of [RFC4379] specifies Target FEC stack validation
+   procedures.  This document enhances the FEC validation procedures as
+   follows.  If the outermost FEC of the target FEC stack is the Nil
+   FEC, then the node MUST skip the target FEC validation completely.
+   This is to support FEC hiding, in which the outer hidden FEC can be
+   the Nil FEC.
+
+4.2.  Modification to FEC Validation Procedure on Egress
+
+   Section 4.4 of [RFC4379] specifies Target FEC stack validation
+   procedures.  This document enhances the FEC validation procedures as
+   follows.  If the outermost FEC of the Target FEC stack is the Nil
+   FEC, then the node MUST skip the target FEC validation completely.
+   This is to support FEC hiding, in which the outer hidden FEC can be
+   the Nil FEC.
+
+
+
+
+
+Bahadur, et al.              Standards Track                   [Page 16]
+
+RFC 6424               LSP Ping over MPLS Tunnels          November 2011
+
+
+4.3.  Ingress Node Procedure
+
+   It is the responsibility of an ingress node to understand tunnel
+   within tunnel semantics and LSP stitching semantics when performing a
+   MPLS traceroute.  This section describes the ingress node procedure
+   based on the kind of reply an ingress node receives from a transit
+   node.
+
+4.3.1.  Processing Downstream Detailed Mapping TLV
+
+   Downstream Detailed Mapping TLV should be processed in the same way
+   as the Downstream Mapping TLV, defined in Section 4.4 of [RFC4379].
+   This section describes the procedures for processing the new elements
+   introduced in this document.
+
+4.3.1.1.  Stack Change Sub-TLV Not Present
+
+   This would be the default behavior as described in [RFC4379].  The
+   ingress node MUST perform MPLS echo reply processing as per the
+   procedures in [RFC4379].
+
+4.3.1.2.  Stack Change Sub-TLV(s) Present
+
+   If one or more FEC stack change sub-TLVs (Section 3.3.1.3) are
+   received in the MPLS echo reply, the ingress node SHOULD process them
+   and perform some validation.
+
+   The FEC stack changes are associated with a downstream neighbor and
+   along a particular path of the LSP.  Consequently, the ingress will
+   need to maintain a FEC stack per path being traced (in case of
+   multipath).  All changes to the FEC stack resulting from the
+   processing of FEC stack change sub-TLV(s) should be applied only for
+   the path along a given downstream neighbor.  The following algorithm
+   should be followed for processing FEC stack change sub-TLVs.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bahadur, et al.              Standards Track                   [Page 17]
+
+RFC 6424               LSP Ping over MPLS Tunnels          November 2011
+
+
+    push_seen = FALSE
+    fec_stack_depth = current-depth-of-fec-stack-being-traced
+    saved_fec_stack = current_fec_stack
+
+    while (sub-tlv = get_next_sub_tlv(downstream_detailed_map_tlv))
+
+        if (sub-tlv == NULL) break
+
+        if (sub-tlv.type == FEC-Stack-Change) {
+
+            if (sub-tlv.operation == POP) {
+                if (push_seen) {
+                    Drop the echo reply
+                    current_fec_stack = saved_fec_stack
+                    return
+                }
+
+                if (fec_stack_depth == 0) {
+                    Drop the echo reply
+                    current_fec_stack = saved_fec_stack
+                    return
+                }
+
+                Pop FEC from FEC stack being traced
+                fec_stack_depth--;
+            }
+
+            if (sub-tlv.operation == PUSH) {
+                push_seen = 1
+                Push FEC on FEC stack being traced
+                fec_stack_depth++;
+            }
+         }
+     }
+
+
+     if (fec_stack_depth == 0) {
+         Drop the echo reply
+         current_fec_stack = saved_fec_stack
+         return
+     }
+
+         Figure 10: FEC Stack Change Sub-TLV Processing Guideline
+
+
+
+
+
+
+
+
+Bahadur, et al.              Standards Track                   [Page 18]
+
+RFC 6424               LSP Ping over MPLS Tunnels          November 2011
+
+
+   The next MPLS echo request along the same path should use the
+   modified FEC stack obtained after processing the FEC stack change
+   sub-TLVs.  A non-Nil FEC guarantees that the next echo request along
+   the same path will have the Downstream Detailed Mapping TLV validated
+   for IP address, Interface address, and label stack mismatches.
+
+   If the top of the FEC stack is a Nil FEC and the MPLS echo reply does
+   not contain any FEC stack change sub-TLVs, then it does not
+   necessarily mean that the LSP has not started traversing a different
+   tunnel.  It could be that the LSP associated with the Nil FEC
+   terminated at a transit node and at the same time a new LSP started
+   at the same transit node.  The Nil FEC would now be associated with
+   the new LSP (and the ingress has no way of knowing this).  Thus, it
+   is not possible to build an accurate hierarchical LSP topology if a
+   traceroute contains Nil FECs.
+
+4.3.2.  Modifications to Handling a Return Code 3 Reply.
+
+   The procedures above allow the addition of new FECs to the original
+   FEC being traced.  Consequently, a reply from a downstream node with
+   Return Code 3 (IS_EGRESS) may not necessarily be for the FEC being
+   traced.  It could be for one of the new FECs that was added.  On
+   receipt of an IS_EGRESS reply, the LSP ingress should check if the
+   depth of Target FEC sent to the node that just responded, was the
+   same as the depth of the FEC that was being traced.  If it was not,
+   then it should pop an entry from the Target FEC stack and resend the
+   request with the same TTL (as previously sent).  The process of
+   popping a FEC is to be repeated until either the LSP ingress receives
+   a non-IS_EGRESS reply or until all the additional FECs added to the
+   FEC stack have already been popped.  Using an IS_EGRESS reply, an
+   ingress can build a map of the hierarchical LSP structure traversed
+   by a given FEC.
+
+4.3.3.  Handling of New Return Codes
+
+   When the MPLS echo reply Return Code is "Label switched with FEC
+   change" (Section 3.2.2), the ingress node SHOULD manipulate the FEC
+   stack as per the FEC stack change sub-TLVs contained in the
+   downstream detailed mapping TLV.  A transit node can use this Return
+   Code for stitched LSPs and for hierarchical LSPs.  In case of ECMP or
+   P2MP, there could be multiple paths and Downstream Detailed Mapping
+   TLVs with different Return Codes (Section 3.2.1).  The ingress node
+   should build the topology based on the Return Code per ECMP path/P2MP
+   branch.
+
+
+
+
+
+
+
+Bahadur, et al.              Standards Track                   [Page 19]
+
+RFC 6424               LSP Ping over MPLS Tunnels          November 2011
+
+
+4.4.  Handling Deprecated Downstream Mapping TLV
+
+   The Downstream Mapping TLV has been deprecated.  Applications should
+   now use the Downstream Detailed Mapping TLV.  The following
+   procedures SHOULD be used for backward compatibility with routers
+   that do not support the Downstream Detailed Mapping TLV.
+
+   o  The Downstream Mapping TLV and the Downstream Detailed Mapping TLV
+      MUST never be sent together in the same MPLS echo request or in
+      the same MPLS echo reply.
+
+   o  If the echo request contains a Downstream Detailed Mapping TLV and
+      the corresponding echo reply contains a Return Code 2 ("One or
+      more of the TLVs was not understood"), then the sender of the echo
+      request MAY resend the echo request with the Downstream Mapping
+      TLV (instead of the Downstream Detailed Mapping TLV).  In cases
+      where a detailed reply is needed, the sender can choose to ignore
+      the router that does not support the Downstream Detailed Mapping
+      TLV.
+
+   o  If the echo request contains a Downstream Mapping TLV, then a
+      Downstream Detailed Mapping TLV MUST NOT be sent in the echo
+      reply.  This is to handle the case that the sender of the echo
+      request does not support the new TLV.  The echo reply MAY contain
+      Downstream Mapping TLV(s).
+
+   o  If echo request forwarding is in use (such that the echo request
+      is processed at an intermediate LSR and then forwarded on), then
+      the intermediate router is responsible for making sure that the
+      TLVs being used among the ingress, intermediate and destination
+      are consistent.  The intermediate router MUST NOT forward an echo
+      request or an echo reply containing a Downstream Detailed Mapping
+      TLV if it itself does not support that TLV.
+
+5.  Security Considerations
+
+   1.  If a network operator wants to prevent tracing inside a tunnel,
+       one can use the Pipe Model [RFC3443], i.e., hide the outer MPLS
+       tunnel by not propagating the MPLS TTL into the outer tunnel (at
+       the start of the outer tunnel).  By doing this, MPLS traceroute
+       packets will not expire in the outer tunnel and the outer tunnel
+       will not get traced.
+
+   2.  If one doesn't wish to expose the details of the new outer LSP,
+       then the Nil FEC can be used to hide those details.  Using the
+       Nil FEC ensures that the trace progresses without false negatives
+       and all transit nodes (of the new outer tunnel) perform some
+       minimal validations on the received MPLS echo requests.
+
+
+
+Bahadur, et al.              Standards Track                   [Page 20]
+
+RFC 6424               LSP Ping over MPLS Tunnels          November 2011
+
+
+   Other security considerations, as discussed in [RFC4379], are also
+   applicable to this document.
+
+6.  IANA Considerations
+
+6.1.  New TLV
+
+   IANA has assigned a TLV type value to the following TLV from the
+   "Multiprotocol Label Switching Architecture (MPLS) Label Switched
+   Paths (LSPs) Ping Parameters" registry, "TLVs and sub-TLVs" sub-
+   registry.
+
+   Downstream Detailed Mapping TLV (see Section 3.3): 20.
+
+6.2.  New Sub-TLV Types and Associated Registry
+
+   IANA has registered the Sub-Type field of Downstream Detailed Mapping
+   TLV.  The valid range for this is 0-65535.  Assignments in the range
+   0-16383 and 32768-49161 are made via Standards Action as defined in
+   [RFC3692]; assignments in the range 16384-31743 and 49162-64511 are
+   made via Specification Required [RFC4379]; values in the range 31744-
+   32767 and 64512-65535 are for Vendor Private Use, and MUST NOT be
+   allocated.  If a sub-TLV has a Type that falls in the range for
+   Vendor Private Use, the Length MUST be at least 4, and the first four
+   octets MUST be that vendor's SMI Enterprise Code, in network octet
+   order.  The rest of the Value field is private to the vendor.
+
+   IANA has assigned the following sub-TLV types (see Section 3.3.1):
+
+   Multipath data: 1
+
+   Label stack: 2
+
+   FEC stack change: 3
+
+6.3.  New Return Codes
+
+   IANA has assigned new Return Code values from the "Multi-Protocol
+   Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters"
+   registry, "Return Codes" sub-registry, as follows using a Standards
+   Action value.
+
+       Value    Meaning
+       -----    -------
+       14       See DDM TLV for Return Code and Return Subcode
+       15       Label switched with FEC change
+
+
+
+
+
+Bahadur, et al.              Standards Track                   [Page 21]
+
+RFC 6424               LSP Ping over MPLS Tunnels          November 2011
+
+
+7.  Acknowledgements
+
+   The authors would like to thank Yakov Rekhter and Adrian Farrel for
+   their suggestions on the document.
+
+8.  References
+
+8.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3692]  Narten, T., "Assigning Experimental and Testing Numbers
+              Considered Useful", BCP 82, RFC 3692, January 2004.
+
+   [RFC4379]  Kompella, K. and G. Swallow, "Detecting Multi-Protocol
+              Label Switched (MPLS) Data Plane Failures", RFC 4379,
+              February 2006.
+
+8.2.  Informative References
+
+   [RFC3443]  Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing
+              in Multi-Protocol Label Switching (MPLS) Networks",
+              RFC 3443, January 2003.
+
+   [RFC4461]  Yasukawa, S., "Signaling Requirements for Point-to-
+              Multipoint Traffic-Engineered MPLS Label Switched Paths
+              (LSPs)", RFC 4461, April 2006.
+
+   [RFC5150]  Ayyangar, A., Kompella, K., Vasseur, JP., and A. Farrel,
+              "Label Switched Path Stitching with Generalized
+              Multiprotocol Label Switching Traffic Engineering (GMPLS
+              TE)", RFC 5150, February 2008.
+
+   [RFC5331]  Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream
+              Label Assignment and Context-Specific Label Space",
+              RFC 5331, August 2008.
+
+   [RFC5462]  Andersson, L. and R. Asati, "Multiprotocol Label Switching
+              (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic
+              Class" Field", RFC 5462, February 2009.
+
+
+
+
+
+
+
+
+
+
+Bahadur, et al.              Standards Track                   [Page 22]
+
+RFC 6424               LSP Ping over MPLS Tunnels          November 2011
+
+
+Authors' Addresses
+
+   Nitin Bahadur
+   Juniper Networks, Inc.
+   1194 N. Mathilda Avenue
+   Sunnyvale, CA  94089
+   US
+
+   Phone: +1 408 745 2000
+   EMail: nitinb@juniper.net
+   URI:   www.juniper.net
+
+
+   Kireeti Kompella
+   Juniper Networks, Inc.
+   1194 N. Mathilda Avenue
+   Sunnyvale, CA  94089
+   US
+
+   Phone: +1 408 745 2000
+   EMail: kireeti@juniper.net
+   URI:   www.juniper.net
+
+
+   George Swallow
+   Cisco Systems
+   1414 Massachusetts Ave
+   Boxborough, MA  01719
+   US
+
+   EMail: swallow@cisco.com
+   URI:   www.cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bahadur, et al.              Standards Track                   [Page 23]
+