--- 1/draft-ietf-mpls-return-path-specified-lsp-ping-07.txt 2012-08-31 04:15:04.585342021 +0200 +++ 2/draft-ietf-mpls-return-path-specified-lsp-ping-08.txt 2012-08-31 04:15:04.641341619 +0200 @@ -1,24 +1,24 @@ Network Working Group M. Chen Internet-Draft W. Cao Intended status: Standards Track Huawei Technologies Co., Ltd -Expires: February 22, 2013 S. Ning +Expires: February 28, 2013 S. Ning Tata Communications F. Jounay Orange CH S. Delord Alcatel-Lucent - August 21, 2012 + August 27, 2012 Return Path Specified LSP Ping - draft-ietf-mpls-return-path-specified-lsp-ping-07.txt + draft-ietf-mpls-return-path-specified-lsp-ping-08.txt Abstract This document defines extensions to the failure-detection protocol for Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) known as "LSP Ping" that allow selection of the LSP to use for the echo reply return path. Enforcing a specific return path can be used to verify bidirectional connectivity and also increase LSP ping robustness. It may also be used by Bidirectional Forwarding Detection (BFD) for MPLS bootstrap signaling thereby making BFD for @@ -38,21 +38,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on February 22, 2013. + This Internet-Draft will expire on February 28, 2013. Copyright Notice Copyright (c) 2012 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 @@ -78,23 +78,23 @@ 3.3.2. IPv6 RSVP Tunnel sub-TLV . . . . . . . . . . . . . . . 11 3.3.3. Static Tunnel sub-TLV . . . . . . . . . . . . . . . . 12 3.4. Reply TC TLV . . . . . . . . . . . . . . . . . . . . . . . 12 4. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 13 4.1. Sending an Echo Request . . . . . . . . . . . . . . . . . 14 4.2. Receiving an Echo Request . . . . . . . . . . . . . . . . 14 4.3. Sending an Echo Reply . . . . . . . . . . . . . . . . . . 15 4.4. Receiving an Echo Reply . . . . . . . . . . . . . . . . . 16 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 - 6.1. New TLV . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 6.1. Temporary assigned TLV and New TLV . . . . . . . . . . . . 17 6.2. Sub-TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 17 - 6.2.1. New Sub-TLVs . . . . . . . . . . . . . . . . . . . . . 17 + 6.2.1. Dedicated Sub-TLVs to Reply Path TLV . . . . . . . . . 17 6.3. New Reply Mode . . . . . . . . . . . . . . . . . . . . . . 18 6.4. Reply Path Return Code . . . . . . . . . . . . . . . . . . 18 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 18 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 9.1. Normative References . . . . . . . . . . . . . . . . . . . 19 9.2. Informative References . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 1. Introduction @@ -295,22 +295,22 @@ was not understood 0x0003 The echo reply was sent successfully using the specified Reply Path 0x0004 The specified Reply Path was not found, the echo reply was sent via other LSP 0x0005 The specified Reply Path was not found, the echo reply was sent via IP path 0x0006 The Reply mode in echo request was not set to 5(Reply via Specified Path) although Reply Path TLV exists 0x0007 Reply Path TLV was missing in echo request - 0x0008-0x1fff Not allocated, allocated via Standard Action - 0x2000-0xffff Experimental Use + 0x0008-0xfffb Not allocated, allocated via Standard Action + 0xfffc-0xffff Experimental Use Flag field is also 2 octets in length, it is used to notify the egress how to process the Reply Paths field when performing return path selection. The Flag field is a bit vector and has following format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MUST be zero |A|B| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -337,46 +337,53 @@ TLV MUST be carried, which describes the specified path that the echo reply message is required to follow. When the Reply Mode field is set to "Reply via Specified Path" in an LSP echo request message, the Reply Path TLV MUST be present. 3.3. Reply Path sub-TLVs Each of the FEC sub-TLVs (include existing and future defined) for the Target FEC Stack TLV[RFC4379] is applicable to be a sub-TLV for inclusion in the Reply Path TLV for expressing a specific return - path. + path. For these shared sub-TLVs, they share the same registry with + the Target FEC Stack TLV for the range of 0-31743 and 32768-64511. - In addition, three more new sub-TLVs are defined: IPv4 RSVP Tunnel - sub-TLV, IPv6 RSVP Tunnel sub-TLV and Static Tunnel sub-TLV. + In addition, this document defines three new sub-TLVs: IPv4 RSVP + Tunnel sub-TLV, IPv6 RSVP Tunnel sub-TLV and Static Tunnel sub-TLV. + These sub-TLVs are only designed for Reply Path TLV, hence this + document calls them dedicated sub-TLVs to Reply Path TLV. For these + dedicated sub-TLVs, this document will create a new registry (Section + 6.1), the sub-TLV type MUST be allocated from the new registry. Detailed definition is in the following sections. - For the shared sub-TLVs, they will share the same registry with the - Target FEC Stack TLV registry for the range of 0-31743 and 32768- - 64511. - - For the dedicated sub-TLVs to Reply Path TLV, this document will - create a new registry (Section 6.1), the sub-TLV type MUST be - allocated from the new registry. + In [RFC4379], the range of 31744-32767 and 64512-65535 for sub-TLVs + is specified for Vendor Private Use, and MUST NOT be allocated. This + document changes that rule to make it not applicable to Reply Path + TLV and redefines the rule as in Section 6.2 . If an implementation + recognizes any specific Vendor Private types as defined in [RFC4379], + and uses the sub-TLV type specified in this document, care must be + taken to ensure that the implementation does not confuse the two + usages. With the Return Path TLV flags and the sub-TLVs defined for the Target FEC Stack TLV and in this document, it could provide following options for return paths specifying: 1. Specify a particular LSP as return path - use those sub-TLVs defined for the Target FEC Stack TLV 2. Specify a more generic tunnel FEC as return path - - use the IPv4/IPv6 RSVP Tunnel sub-TLVs defined in Section - 3.3.1 and Section 3.3.2 of this document + - use the IPv4/IPv6 RSVP and Static Tunnel sub-TLVs defined in + Section 3.3.1, Section 3.3.2 and Section 3.3.3 of this + document 3. Specify the reverse path of the bidirectional LSP as return path - use B bit defined in Section 3.2 of this document. 4. Force return path to non-default path - use A bit defined in Section 3.2 of this document. 3.3.1. IPv4 RSVP Tunnel sub-TLV @@ -402,30 +409,29 @@ | IPv4 tunnel sender address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 IPv4 RSVP Tunnel sub-TLV The IPv4 RSVP Tunnel sub-TLV is derived from the RSVP IPv4 FEC TLV that is defined in Section 3.2.3 [RFC4379]. All fields have the same semantics as defined in [RFC4379] except that the LSP-ID field is omitted and a new Flag field is defined. The IPv4 RSVP Tunnel sub-TLV Type field is 2 octets in length, and - the recommended type value is 18 (to be confirmed by IANA). + the recommended type value is TBD. The Flag field is 2 octets in length, it is used to notify the egress LSR how to choose the return path. The Flag field is a bit vector and has following format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | MUST be zero |S|P| + |S|P| MUST be zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - P (Primary): the return path MUST be chosen from the LSPs that belong to the specified Tunnel and the LSP MUST be the primary LSP. S (Secondary): the return path MUST be chosen from the LSPs that belong to the specified Tunnel and the LSP MUST be the secondary LSP. P bit and S bit MUST NOT both be set, otherwise, an echo reply with the RP return code set to "Malformed RP TLV was received" SHOULD be returned. If P bit and S bit are both not set, the return path could be any one of the LSPs from the same Tunnel. @@ -499,20 +505,22 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Tunnel Num | Destination Tunnel Num | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flag | Must Be Zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4 Static Tunnel sub-TLV The Flag field is 2 octets in length and is identical to that described in Section 3.3.1. + The sub-TLV type value is TBD. + 3.4. Reply TC TLV Reply TOS Byte TLV [RFC4379] is used by the originator of the echo request to request that an echo reply be sent with the IP header TOS byte set to the value specified in the TLV. Similarly, in this document, a new TLV: Reply TC TLV is defined and MAY be used by the originator of the echo request to request that an echo reply be sent with the TC bits of the return path LSP set to the value specified in this TLV. The format of Reply TC TLV is as follows: @@ -521,21 +529,21 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reply TC TLV type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TC | MUST be zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Reply TC TLV Type field is 2 octets in length, and the type value is TBD. The Length field is 2 octets in length, the value of length field is - fixed 4. + fixed 4 octets. 4. Theory of Operation The procedures defined in this document currently only apply to "ping" mode. The "traceroute" mode is out of scope for this document. In [RFC4379], the echo reply is used to report the LSP checking result to the LSP Ping initiator. This document defines a new reply mode and a new TLV (Reply Path TLV) that enable the LSP ping @@ -689,78 +697,82 @@ 5. Security Considerations Security considerations discussed in [RFC4379] apply to this document. In addition to that, in order to prevent using the extension defined in this document for "proxying" any possible attacks, the return path LSP MUST have destination to the same node where the forward path is from. 6. IANA Considerations - IANA is requested to assign two new TLVs from the "Multiprotocol + IANA has a temporary allocation for a TLV from the "Multiprotocol Label Switching Architecture (MPLS) Label Switched Paths (LSPs) Ping - Parameters - TLVs" registry, "TLVs and sub-TLVs" sub- registry; block - the standards action sub-TLVs for TLV Type 21 from being allocated; - one new Reply Mode from the "Multi-Protocol Label Switching (MPLS) - Label Switched Paths (LSPs) Ping Parameters" registry, the "Reply - Mode" subregistry. - -6.1. New TLV - - The IANA is requested to as assign two new TLVs from the + Parameters - TLVs" registry, "TLVs and sub-TLVs" sub-registry - Type + 21 (Reply Path TLV). For this TLV the standards action sub-TLVs (the + range of 0-31743 and 32768-64511) shall be blocked from being + allocated. IANA is also requested to assign one new TLV from the "Multiprotocol Label Switching Architecture (MPLS) Label Switched Paths (LSPs) Ping Parameters - TLVs" registry, "TLVs and sub-TLVs" sub- registry. +6.1. Temporary assigned TLV and New TLV + + The IANA is requested to assign the temporary assigned Reply path TLV + and also assign one new TLV from the "Multiprotocol Label Switching + Architecture (MPLS) Label Switched Paths (LSPs) Ping Parameters - + TLVs" registry, "TLVs and sub-TLVs" sub-registry. + + Note: IANA have made an early allocation of the value 21 for Reply + Path TLV. + Value Meaning Reference ----- ------- --------- 21 Reply Path TLV this document (sect 3.2) TBD Reply TC TLV this document (sect 3.4) 6.2. Sub-TLVs The sub-TLV range of Reply Path TLV are partitioned as following: 0-31743 - Reserved, and MUST NOT be allocated. 31744-32767 - Allocated via Standards Action. 32768-64511 - Reserved, and MUST NOT be allocated. - 64512-65535 - Experimental Use, and MUST NOT be allocated. + 64512-65531 - Allocated via Standards Action. - In [RFC4379], the range of 31744-32767 for sub-TLVs are specified for - Vendor Private Use, and MUST NOT be allocated. This document changes - rule to make it not apply to Reply Path TLV. If an implementation - recognizes any specific Vendor Private types as defined in [RFC4379], - and uses the sub-TLV type specified in this document, care must be - taken to ensure that the implementation does not confuse the two - usages. + 65531-65535 - Experimental Use, and MUST NOT be allocated. -6.2.1. New Sub-TLVs +6.2.1. Dedicated Sub-TLVs to Reply Path TLV IANA is also requested to assign three new sub-TLV types from "Multiprotocol Label Switching Architecture (MPLS) Label Switched Paths (LSPs) Ping Parameters - TLVs" registry, "TLVs and sub-TLVs" - sub- registry for the Reply Path TLV (Type 21). The following sub- - type MUST be assigned from the range of 31744-32767. + sub-registry for the Reply Path TLV (Type 21) - from the Standards + Action range. Sub-type Value Field Reference ------- ----------- --------- TBD IPv4 RSVP Tunnel this document (sect 3.3.1) TBD IPv6 RSVP Tunnel this document (sect 3.3.2) TBD Static Tunnel this document (sect 3.3.3) + Previously temporary allocated sub-TLVs fall within the blocked range + an should NOT be allocated. + 6.3. New Reply Mode - IANA is requested to assign a new reply mode code point from the - "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) - Ping Parameters" registry, the "Reply Mode" subregistry. + IANA is now requested to assign the previously assigned a new reply + mode code point (5 - Reply via specified path) from the "Multi- + Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping + Parameters" registry, the "Reply Mode" sub-registry on a permanent + basis. Value Meaning Reference ----- ------- ---------- 5 Reply via Specified Path this document (sect 3.1) 6.4. Reply Path Return Code IANA is requested to create a new registry for Reply Path return code. This document (Section 3.2) defines the following return codes: @@ -773,26 +785,26 @@ was not understood 0x0003 The echo reply was sent successfully using the specified Reply Path 0x0004 The specified Reply Path was not found, the echo reply was sent via other LSP 0x0005 The specified Reply Path was not found, the echo reply was sent via IP path 0x0006 The Reply mode in echo request was not set to 5(Reply via Specified Path) although Reply Path TLV exists 0x0007 Reply Path TLV was missing in echo request - 0x0008-0x1fff Not allocated, allocated via Standard Action - 0x2000-0xffff Experimental Use + 0x0008-0xfffb Not allocated, allocated via Standard Action + 0xfffc-0xffff Experimental Use - The range of 0x0008-0x1fff are not allocated and reserved for future - extensions and MUST be allocated via Standard Action, the range of - 0x2000-0xffff are for Experimental Use. + The range of 0x0008-0xfffb is not allocated and reserved for future + extensions and is allocated via Standard Action, the range of 0xfffc- + 0xffff is for Experimental Use. 7. Contributors The following individuals also contributed to this document: Ehud Doron Orckit-Corrigent EMail: ehudd@orckit.com Ronen Solomon