draft-ietf-mpls-lsp-ping-enhanced-dsmap-03.txt   draft-ietf-mpls-lsp-ping-enhanced-dsmap-04.txt 
Network Working Group N. Bahadur Network Working Group N. Bahadur
Internet-Draft K. Kompella Internet-Draft K. Kompella
Updates: RFC4379 Juniper Networks, Inc. Updates: RFC4379 Juniper Networks, Inc.
(if approved) G. Swallow (if approved) G. Swallow
Intended status: Standards Track Cisco Systems Intended status: Standards Track Cisco Systems
Expires: January 12, 2010 July 11, 2009 Expires: April 26, 2010 October 23, 2009
Mechanism for performing LSP-Ping over MPLS tunnels Mechanism for performing LSP-Ping over MPLS tunnels
draft-ietf-mpls-lsp-ping-enhanced-dsmap-03 draft-ietf-mpls-lsp-ping-enhanced-dsmap-04
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 1, line 44 skipping to change at page 1, line 44
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 12, 2010. This Internet-Draft will expire on April 26, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 3, line 19 skipping to change at page 3, line 19
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Packet format . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Packet format . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. New Return Codes . . . . . . . . . . . . . . . . . . . . . 6 3.2. New Return Codes . . . . . . . . . . . . . . . . . . . . . 6
3.2.1. Return code per downstream . . . . . . . . . . . . . . 6 3.2.1. Return code per downstream . . . . . . . . . . . . . . 6
3.2.2. Return code for stitched LSPs . . . . . . . . . . . . 6 3.2.2. Return code for stitched LSPs . . . . . . . . . . . . 6
3.3. Downstream Detailed Mapping TLV . . . . . . . . . . . . . 6 3.3. Downstream Detailed Mapping TLV . . . . . . . . . . . . . 6
3.3.1. Multipath data sub-TLV . . . . . . . . . . . . . . . . 8 3.3.1. Multipath data sub-TLV . . . . . . . . . . . . . . . . 8
3.3.2. Label stack sub-TLV . . . . . . . . . . . . . . . . . 9 3.3.2. Label stack sub-TLV . . . . . . . . . . . . . . . . . 9
3.3.3. FEC Stack change sub-TLV . . . . . . . . . . . . . . . 9 3.3.3. FEC Stack change sub-TLV . . . . . . . . . . . . . . . 9
3.4. Deprecation of Downstream Mapping TLV . . . . . . . . . . 11 3.4. Deprecation of Downstream Mapping TLV . . . . . . . . . . 12
4. Performing lsp-ping traceroute on tunnels . . . . . . . . . . 12 4. Performing lsp-ping traceroute on tunnels . . . . . . . . . . 12
4.1. Transit node procedure . . . . . . . . . . . . . . . . . . 12 4.1. Transit node procedure . . . . . . . . . . . . . . . . . . 12
4.1.1. Addition of a new tunnel . . . . . . . . . . . . . . . 12 4.1.1. Addition of a new tunnel . . . . . . . . . . . . . . . 12
4.1.2. Transition between tunnels . . . . . . . . . . . . . . 12 4.1.2. Transition between tunnels . . . . . . . . . . . . . . 13
4.2. Ingress node procedure . . . . . . . . . . . . . . . . . . 14 4.2. Ingress node procedure . . . . . . . . . . . . . . . . . . 15
4.2.1. Processing Downstream Detailed Mapping TLV . . . . . . 14 4.2.1. Processing Downstream Detailed Mapping TLV . . . . . . 15
4.2.1.1. Stack Change sub-TLV not present . . . . . . . . . 15 4.2.1.1. Stack Change sub-TLV not present . . . . . . . . . 15
4.2.1.2. Stack Change sub-TLV(s) present . . . . . . . . . 15 4.2.1.2. Stack Change sub-TLV(s) present . . . . . . . . . 15
4.2.2. Modifications to handling to EGRESS_OK responses. . . 17 4.2.2. Modifications to handling to EGRESS_OK responses. . . 17
4.2.3. Handling of new return codes . . . . . . . . . . . . . 17 4.2.3. Handling of new return codes . . . . . . . . . . . . . 17
4.3. Handling deprecated Downstream Mapping TLV . . . . . . . . 17 4.3. Handling deprecated Downstream Mapping TLV . . . . . . . . 17
5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.1. Normative References . . . . . . . . . . . . . . . . . . . 20 8.1. Normative References . . . . . . . . . . . . . . . . . . . 20
skipping to change at page 6, line 19 skipping to change at page 6, line 19
format. In summary, the draft makes the following TLV changes: format. In summary, the draft makes the following TLV changes:
o Addition of new Downstream Detailed Mapping TLV (DDMAP). o Addition of new Downstream Detailed Mapping TLV (DDMAP).
o Deprecation of existing Downstream Mapping TLV. o Deprecation of existing Downstream Mapping TLV.
o Addition of Downstream FEC Stack Change Sub-TLV to DDMAP. o Addition of Downstream FEC Stack Change Sub-TLV to DDMAP.
3.2. New Return Codes 3.2. New Return Codes
3.2.1. Return code per downstream 3.2.1. Return code per downstream
A new return code is being defined "See DDM TLV for Return Code and 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 Return SubCode" (Section 6.3) to indicate that the Return Code is per
Detailed Downstream Mapping TLV (Section 3.3). This return code MUST 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 echo be used only in the message header and MUST be set only in the echo
response message. If the return code is set in the echo request response message. If the Return Code is set in the echo request
message, then it SHOULD be ignored. When this return code is set, message, then it SHOULD be ignored. When this Return Code is set,
each Detailed Downstream Mapping TLV MUST have an appropriate return each Detailed Downstream Mapping TLV MUST have an appropriate Return
code and return subcode. This return code is to be used when there Code and Return SubCode. This Return Code is to be used when there
are multiple downstreams for a given node (such as P2MP or ECMP), and are multiple downstreams for a given node (such as P2MP or ECMP), and
the node wants to return a different return code/return subcode for the node wants to return a different Return Code/Return SubCode for
each downstream. each downstream.
3.2.2. Return code for stitched LSPs 3.2.2. Return code for stitched LSPs
When a traceroute is being performed on stitched LSPs Figure 10, the When a traceroute is being performed on stitched LSPs Figure 10, the
stitching point SHOULD indicate the stitching action to the node stitching point SHOULD indicate the stitching action to the node
performing the trace. This is done by setting the return code to performing the trace. This is done by setting the Return Code to
"Label switched with FEC change" (Section 6.3). If a node is "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 performing FEC hiding, then it MAY choose to set the Return Code to a
value other than "Label switched with FEC change". This return code value other than "Label switched with FEC change". This Return Code
MUST NOT be used if no Label Stack sub-TLVs (Section 3.3.3) are MUST NOT be used if no Label Stack sub-TLVs (Section 3.3.3) are
present in the Detailed Downstream Mapping TLV(s). This new return present in the Detailed Downstream Mapping TLV(s). This new Return
code MAY be used for hierarchical LSPs (for indicating start or end Code MAY be used for hierarchical LSPs (for indicating start or end
of an outer LSP). of an outer LSP).
3.3. Downstream Detailed Mapping TLV 3.3. Downstream Detailed Mapping TLV
A new TLV has been added to the mandatory range of TLVs. The TLV A new TLV has been added to the mandatory range of TLVs. The TLV
type is pending IANA allocation. type is pending IANA allocation.
Type # Value Field Type # Value Field
------ ------------ ------ ------------
skipping to change at page 8, line 4 skipping to change at page 8, line 4
Downstream Mapping TLV format. The key change is that variable Downstream Mapping TLV format. The key change is that variable
length and optional fields have been coverted into sub-TLVs. The length and optional fields have been coverted into sub-TLVs. The
fields have the same use and meaning as in [RFC4379]. The newly fields have the same use and meaning as in [RFC4379]. The newly
added sub-TLVs and their fields are as described below. added sub-TLVs and their fields are as described below.
Return code Return code
The Return Code and Return SubCode are set to zero by the sender. The Return Code and Return SubCode are set to zero by the sender.
The receiver can set it to one of the values specified in the The receiver can set it to one of the values specified in the
"Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs)
Parameters" registry, "Return Codes" sub-registry. The notation Parameters" registry, "Return Codes" sub-registry. The notation
<RSC> refers to the Return Subcode. This field is filled in with <RSC> refers to the Return SubCode. This field is filled in with
the stack-depth for those codes that specify that. For all other the stack-depth for those codes that specify that. For all other
codes, the Return Subcode MUST be set to zero. codes, the Return SubCode MUST be set to zero.
If the receiver sets the value of Return Code and Return SubCode If the receiver sets a non-zero value of the Return Code field in
in the Downstream Detailed Mapping TLV, then the receiver MUST set the Downstream Detailed Mapping TLV, then the receiver MUST also
the Return Code in the echo response header to "See DDM TLV for set the Return Code field in the echo response header to "See DDM
Return Code and Return SubCode" Section 6.3). TLV for Return Code and Return SubCode" (Section 6.3). An
If the Return Code of the echo response message is not set to "See exception to this is if the receiver is a bud node and is replying
DDM TLV for Return Code and Return SubCode" Section 6.3, then the as both an egress and a transit node with a Return Code of 3
Return Code and Return SubCode specified in the Downstream ("Replying router is an egress for the FEC") in the echo response
header.
If the Return Code of the echo response 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", then
the Return Code and Return SubCode specified in the Downstream
Detailed Mapping TLV SHOULD be ignored. Detailed Mapping TLV SHOULD be ignored.
Sub-tlv length Sub-tlv length
Total length in bytes of the sub-TLVs associated with this TLV. Total length in bytes of the sub-TLVs associated with this TLV.
Sub-Type Value Field Sub-Type Value Field
--------- ------------ --------- ------------
TBD Multipath data TBD Multipath data
TBD Label stack TBD Label stack
TBD FEC Stack change TBD FEC Stack change
skipping to change at page 9, line 27 skipping to change at page 9, line 29
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Label Stack Sub-TLV Figure 7: Label Stack Sub-TLV
The Label stack sub-TLV contains the set of labels in the label stack 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 as it would have appeared if this router were forwarding the packet
through this interface. Any Implicit Null labels are explicitly through this interface. Any Implicit Null labels are explicitly
included. The number of labels present in the sub-TLV is determined included. The number of labels present in the sub-TLV is determined
based on the sub-TLV data length. Labels are treated as numbers, based on the sub-TLV data length. Labels are treated as numbers,
i.e., they are right justified in the field. The label format and i.e., they are right justified in the field. The label format and
protocol type are as defined in [RFC4379]. When the Detailed protocol type are as defined in [RFC4379]. When the Downstream
Downstream Mapping TLV in sent in the echo response, this sub-TLV Detailed Mapping TLV in sent in the echo response, this sub-TLV MUST
MUST be included. be included.
3.3.3. FEC Stack change sub-TLV 3.3.3. FEC Stack change sub-TLV
A router SHOULD include the the FEC Stack change sub-TLV when the A router SHOULD include the the FEC Stack change sub-TLV when the
downstream node in the echo response has a different FEC stack than downstream node in the echo response has a different FEC stack than
the FEC stack received in the echo request. One or more FEC Stack the FEC stack received in the echo request. One or more FEC Stack
change sub-TLVs MAY be present in the Downstream Detailed Mapping change sub-TLVs MAY be present in the Downstream Detailed Mapping
TLV. The format is as below. TLV. The format is as below.
0 1 2 3 0 1 2 3
skipping to change at page 13, line 7 skipping to change at page 13, line 21
\_____/ \______/ \______/ \______/ \_______/ \_____/ \______/ \______/ \______/ \_______/
LDP LDP BGP RSVP RSVP LDP LDP BGP RSVP RSVP
Figure 10: Stitched LSPs Figure 10: Stitched LSPs
In the above figure, we have 3 seperate LSP segments stitched at C In the above figure, we have 3 seperate LSP segments stitched at C
and D. Node C SHOULD include 2 FEC Stack change sub-TLVs. One with a and D. Node C SHOULD include 2 FEC Stack change sub-TLVs. One with a
POP operation for the LDP FEC and one with the PUSH operation for the POP operation for the LDP FEC and one with the PUSH operation for the
BGP FEC. Similarly, node D SHOULD include 2 FEC Stack change sub- BGP FEC. Similarly, node D SHOULD include 2 FEC Stack change sub-
TLVs, one with a POP operation for the BGP FEC and one with a PUSH 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 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 to "Label switched with FEC change" (Section 6.3) to indicate change
in FEC being traced. in FEC being traced.
If node C wishes to perform FEC hiding, it SHOULD respond back with 2 If node C wishes to perform FEC hiding, it SHOULD respond back with 2
FEC Stack change sub-TLVs. One POP followed by 1 PUSH. The POP FEC Stack change sub-TLVs. One POP followed by 1 PUSH. The POP
operation MAY either exclude the FEC TLV (by setting FEC TLV length operation MAY either exclude the FEC TLV (by setting FEC TLV length
to 0) or set the FEC TLV to contain the LDP FEC. The PUSH operation to 0) or set the FEC TLV to contain the LDP FEC. The PUSH operation
SHOULD have the FEC TLV containing the NIL FEC. The return code SHOULD have the FEC TLV containing the NIL FEC. The Return Code
SHOULD be set to "Label switched with FEC change". SHOULD be set to "Label switched with FEC change".
If node C performs FEC hiding and node D also performs FEC hiding, 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 then node D MAY choose to not send any FEC Stack change sub-TLVs in
the echo response since the number of labels has not changed (for the the echo response since the number of labels has not changed (for the
downstream of node D) and the FEC type also has not changed (NIL 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 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 switched with FEC change". If node D performs FEC hiding, then node
F will respond as EGRESS_OK for the NIL FEC. The ingress (node A) F will respond as EGRESS_OK for the NIL FEC. The ingress (node A)
will know that EGRESS_OK corresponds to the end-to-end LSP. will know that EGRESS_OK corresponds to the end-to-end LSP.
A B C D E F A B C D E F
o -------- o -------- o --------- o --------- o --------- o o -------- o -------- o --------- o --------- o --------- o
\_____/ |\____________________/ |\_______/ \_____/ |\____________________/ |\_______/
LDP |\ RSVP-A | LDP LDP |\ RSVP-A | LDP
| \_______________________________/| | \_______________________________/|
| RSVP-B | | RSVP-B |
skipping to change at page 13, line 47 skipping to change at page 14, line 25
In the above figure, the following sequence of FEC Stack change sub- In the above figure, the following sequence of FEC Stack change sub-
TLVs will be performed TLVs will be performed
Node B: Node B:
Respond with 2 FEC Stack change sub-TLVs: PUSH RSVP-B, PUSH RSVP-A. Respond with 2 FEC Stack change sub-TLVs: PUSH RSVP-B, PUSH RSVP-A.
Node D: Node D:
Respond with a return code of EGRESS_OK when RSVP-A is top of FEC Respond with a Return Code of EGRESS_OK when RSVP-A is top of FEC
stack. Downstream information for node E when echo request contains stack. Downstream information for node E when echo request contains
RSVP-B as top of FEC stack and an appropriate return code. RSVP-B as top of FEC stack and an appropriate Return Code.
If node B is performing tunnel hiding, then: If node B is performing tunnel hiding, then:
Node B: Node B:
Respond with 2 FEC Stack change sub-TLVs: PUSH NIL-FEC, PUSH NIL-FEC. Respond with 2 FEC Stack change sub-TLVs: PUSH NIL-FEC, PUSH NIL-FEC.
Node D: Node D:
Respond with either return code of EGRESS_OK (if D can co-relate that Respond with either Return Code of EGRESS_OK (if D can co-relate that
the NIL-FEC corresponds to RSVP-A which is terminating at D) or the NIL-FEC corresponds to RSVP-A which is terminating at D) or
respond with FEC Stack change sub-TLV: POP (since D knows that number respond with FEC Stack change sub-TLV: POP (since D knows that number
of labels towards next-hop is decreasing). of labels towards next-hop is decreasing).
A B C D E F G A B C D E F G
o -------- o -------- o ------ o ------ o ----- o ----- o o -------- o -------- o ------ o ------ o ----- o ----- o
LDP LDP BGP \ RSVP RSVP / LDP LDP LDP BGP \ RSVP RSVP / LDP
\_____________/ \_____________/
LDP LDP
Figure 12: Stitched hierarchical LSPs Figure 12: Stitched hierarchical LSPs
In the above case, node D will send 3 FEC Stack change sub-TLVs. One In the above case, node D will send 3 FEC Stack change sub-TLVs. One
POP (for the BGP FEC) followed by 2 PUSHes (one for LDP and one for POP (for the BGP FEC) followed by 2 PUSHes (one for LDP and one for
RSVP). Nodes C and D SHOULD set the return code to "Label switched 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 with FEC change" (Section 6.3) to indicate change in FEC being
traced. traced.
4.2. Ingress node procedure 4.2. Ingress node procedure
It is the responsibility of an ingress node to understand tunnel It is the responsibility of an ingress node to understand tunnel
within tunnel semantics and lsp stitching semantics when performing a within tunnel semantics and lsp stitching semantics when performing a
lsp traceroute. This section describes the ingress node procedure lsp traceroute. This section describes the ingress node procedure
based on the kind of response an ingress node receives from a transit based on the kind of response an ingress node receives from a transit
node. node.
skipping to change at page 17, line 35 skipping to change at page 17, line 35
of the FEC that was being traced. If it was not, then it should pop of the FEC that was being traced. If it was not, then it should pop
the an entry from the Target FEC stack and resend the request with the 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 the same TTL (as previously sent). The process of popping a FEC is
to be repeated until either the ingress receives a non-EGRESS_OK to be repeated until either the ingress receives a non-EGRESS_OK
response or until all the additional FECs added to the FEC stack have response or until all the additional FECs added to the FEC stack have
already been popped. Using EGRESS_OK responses, an ingress can build already been popped. Using EGRESS_OK responses, an ingress can build
a map of the hierarchical LSP structure traversed by a given FEC. a map of the hierarchical LSP structure traversed by a given FEC.
4.2.3. Handling of new return codes 4.2.3. Handling of new return codes
When the echo response return code is "Label switched with FEC When the echo response Return Code is "Label switched with FEC
change" (Section 3.2.2), the ingress node SHOULD manipulate the 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 detailed stack as per the FEC Stack change sub-TLVs contained in the detailed
downstream mapping TLV. A transit node can use this return code for downstream mapping TLV. A transit node can use this Return Code for
stitched LSPs and for hierarchical LSPs. In case of ECMP or P2MP, stitched LSPs and for hierarchical LSPs. In case of ECMP or P2MP,
there could be multiple paths and detailed downstream mapping TLVs there could be multiple paths and detailed downstream mapping TLVs
with different return codes (Section 3.2.1). The ingress node should with different return codes (Section 3.2.1). The ingress node should
build the topology based off the return code per ECMP path/P2MP build the topology based off the Return Code per ECMP path/P2MP
branch. branch.
4.3. Handling deprecated Downstream Mapping TLV 4.3. Handling deprecated Downstream Mapping TLV
The Downstream Mapping TLV has been deprecated. Applications should The Downstream Mapping TLV has been deprecated. Applications should
now use the Downstream Detailed Mapping TLV. The following now use the Downstream Detailed Mapping TLV. The following
procedures SHOULD be used for backward compatibility with routers procedures SHOULD be used for backward compatibility with routers
that do not support the Downstream Detailed Mapping TLV. that do not support the Downstream Detailed Mapping TLV.
o The Downstream Mapping TLV and the Downstream Detailed Mapping TLV o The Downstream Mapping TLV and the Downstream Detailed Mapping TLV
MUST never be sent together in the same echo request or in the MUST never be sent together in the same echo request or in the
same echo response. same echo response.
o If the echo request contains a Downstream Detailed Mapping TLV and o If the echo request contains a Downstream Detailed Mapping TLV and
the corresponding echo response contains an error code of 2 (one the corresponding echo response contains an Return Code of 2 (one
or more of the TLVs was not understood), then the sender of the or more of the TLVs was not understood), then the sender of the
echo request MAY resend the echo request with the Downstream echo request MAY resend the echo request with the Downstream
Mapping TLV (instead of the Downstream Detailed Mapping TLV). In Mapping TLV (instead of the Downstream Detailed Mapping TLV). In
cases where a detailed response is needed, the sender can choose cases where a detailed response is needed, the sender can choose
to ignore the router that does not support the Downstream Detailed to ignore the router that does not support the Downstream Detailed
Mapping TLV. Mapping TLV.
o If the echo request contains a Downstream Mapping TLV, then a o If the echo request contains a Downstream Mapping TLV, then a
Downstream Detailed Mapping TLV MUST NOT be sent in the echo Downstream Detailed Mapping TLV MUST NOT be sent in the echo
response. This is to handle the case that the sender of the echo response. This is to handle the case that the sender of the echo
request does not support the new TLV. request does not support the new TLV.
skipping to change at page 19, line 20 skipping to change at page 19, line 20
6. IANA Considerations 6. IANA Considerations
6.1. New TLV 6.1. New TLV
IANA is requested to assign TLV type value to the following TLV from IANA is requested to assign TLV type value to the following TLV from
the "Multiprotocol Label Switching Architecture (MPLS) Label Switched the "Multiprotocol Label Switching Architecture (MPLS) Label Switched
Paths (LSPs) Parameters - TLVs" registry, "TLVs and sub-TLVs" sub- Paths (LSPs) Parameters - TLVs" registry, "TLVs and sub-TLVs" sub-
registry. registry.
Downstream Detailed Mapping TLV (See Section 3.3). Suggested value: Downstream Detailed Mapping TLV (See Section 3.3). Suggested value:
20. 21.
6.2. New Sub-TLV types and associated registry 6.2. New Sub-TLV types and associated registry
IANA is requested to create a new registry for the Sub-Type field of IANA is requested to create a new registry for the Sub-Type field of
Downstream Detailed Mapping TLV. The valid range for this is Downstream Detailed Mapping TLV. The valid range for this is
0-65535. Assignments in the range 0-16383 and 32768-49161 are made 0-65535. Assignments in the range 0-16383 and 32768-49161 are made
via Standards Action as defined in [RFC3692]; assignments in the via Standards Action as defined in [RFC3692]; assignments in the
range 16384-31743 and 49162-64511 are made via Specification Required range 16384-31743 and 49162-64511 are made via Specification Required
([RFC4379]); values in the range 31744-32767 and 64512-65535 are for ([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 Vendor Private Use, and MUST NOT be allocated. If a sub-TLV has a
 End of changes. 27 change blocks. 
44 lines changed or deleted 50 lines changed or added

This html diff was produced by rfcdiff 1.37a. The latest version is available from http://tools.ietf.org/tools/rfcdiff/