Internet DRAFT - draft-ankur-mpls-upstream-mapping
draft-ankur-mpls-upstream-mapping
Routing Working Group A. Saxena
Internet-Draft M. Jethanandani
Intended status: Standards Track Ciena Corporation
Expires: April 14, 2014 October 11, 2013
Upstream mapping in Echo Request
draft-ankur-mpls-upstream-mapping-00.txt
Abstract
This document describes an enhancement to the Echo Request and Echo
Response message to carry upstream mapping information for co-routed
bidirectional MPLS-TP tunnels.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
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 April 14, 2014.
Copyright Notice
Copyright (c) 2013 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.
Saxena & Jethanandani Expires April 14, 2014 [Page 1]
Internet-Draft Upstream mapping October 2013
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions Used in This Document . . . . . . . . . . . . 2
1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 2
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Packet format . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Return Codes . . . . . . . . . . . . . . . . . . . . . . 3
3.2. Upstream TLV . . . . . . . . . . . . . . . . . . . . . . 3
4. Theory of Operations . . . . . . . . . . . . . . . . . . . . 5
4.1. Usefulness of Upstream TLV in a Bidirectional LSP sharing
the same path . . . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6.1. New TLV . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.2. New Returns Codes . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
Detecting MPLS Data Plane Failures [RFC4379] defines mechanisms for
collecting downstream mapping information using Downstream Mapping
(DSMAP) TLV. However, it does not describe a method by which similar
information can be captured for the upstream mapping. An operator
would generally be interested in the path taken by a packet in both
the downstream and the upstream direction. Currently the only way
the operator would be able to get that information would be by
running the same command from the other end point. This document
describes a method by which both Downstream Mapping (DSMAP) and
Upstream Mapping (UPMAP) information can be collected by the same
device.
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] [RFC2119].
1.2. Abbreviations
+--------------+---------------------+
| Abbreviation | Meaning |
+--------------+---------------------+
| DSMAP | Downstream Mapping |
Saxena & Jethanandani Expires April 14, 2014 [Page 2]
Internet-Draft Upstream mapping October 2013
| | |
| LSP | Label Switched Path |
| | |
| UPMAP | Upstream Mapping |
+--------------+---------------------+
2. Motivation
Detecting MPLS Data Plane Failures [RFC4379], describes the method by
which an operator can find a fault in a bidirectional LSP. The
operator starts by issuing a traceroute command from a node in the
network to a node that is beyond the failed node. The operator then
has to issue the same command from the node that was targeted in the
first command. In many cases, the operator does not have access to
the other node in the network. The operator is however interested in
both the upstream and downstream LSP. This draft suggests a method
by which the operator can issue a single traceroute command from one
of the nodes in the network and mpls echo request and response packet
will carry information to validate both the DSMAP and UPMAP
information. The UPMAP can only be used in case of a bidirectional
LSP, where the Forward LSP and the Reverse LSP share their path.
When used in a non-bidirectional LSP, the UPMAP information will be
filled with zeros and SHOULD be ignored on reception. A router that
does not support the UPMAP TLV will silently ignore the TLV.
3. Packet format
The packet format is similar to the packet format described in
Section 3 of RCF4379. [RFC4379]
This draft proposes to add two new return codes as outlined in
section and a new TLV as specified in section .
3.1. Return Codes
+-------+------------------------------------------+
| Value | Meaning |
+-------+------------------------------------------+
| TBD | Upstream Mapping Mismatch |
| | |
| TBD | Downstream and Upstream Mapping Mismatch |
+-------+------------------------------------------+
3.2. Upstream TLV
Saxena & Jethanandani Expires April 14, 2014 [Page 3]
Internet-Draft Upstream mapping October 2013
The upstream mapping TLV is an object that MUST be included for all
reply modes in the MPLS Echo packet when the operator has requested a
traceroute on a bidirectional LSP, where the Forward LSP and Reverse
LSP share the same path. The presence of an upstream TLV by the
requester means that the replying router SHOULD validate the upstream
TLV and if correct, fill the upstream TLV with upstream FEC of the
replying router. If incorrect, it should fill the return code with
one of the values specified in section to indicate "Upstream Mapping
Mismatch" and leave the upstream TLV as is. If the node is an LER
router and the upstream TLV is included in the MPLS echo request
packet, it SHOULD fill the upstream TLV with the appropriate
information and MUST include it in the MPLS echo reply.
As defined in RFC 4379, the length of this TLV is K + M + 4*N octets,
where M is the Multipath Length, and N is the number of Downstream
Labels. Values for K are found in the description of Address Type
below. The Value field of a Upstream TLV has the following format:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Upstream IP Address (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Upstream Interface Address (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multipath Type| Depth Limit | Multipath Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. (Multipath Information) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Upstream Label | Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Upstream Label | Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Upstream IP Address and Upstream Interface Address
IPv4 addresses and interface indices are encoded in 4 octets; IPv6
addresses are encoded in 16 octets. If the interface to the upstream
node is numbered, then the Address Type MUST be set to IPv4 or IPv6,
Saxena & Jethanandani Expires April 14, 2014 [Page 4]
Internet-Draft Upstream mapping October 2013
the Upstream IP Address MUST be set to either the Upstream node's
Router ID or the interface address of the Upstream node, and the
Upstream Interface Address MUST be set to the upstream node's
interface address. If the interface to the upstream node is
unnumbered, the Address Type MUST be IPv4 Unnumbered or IPv6
Unnumbered, the Upstream IP Address MUST be the upstream node's
Router ID, and the Upstream Interface Address MUST be set to the
index assigned by the node to the interface.
If a node does not know the IP address of its neighbor, then it MUST
set the Address Type to either IPv4 Unnumbered or IPv6 Unnumbered.
For IPv4, it must set the Upstream IP Address to 127.0.0.1; for IPv6
the address is set to 0::1. In both cases, the interface index MUST
be set to 0.
Upstream Label(s)
The set of labels in the label stack should appear as if this router
were forwarding the packet through this interface. Any Implicit Null
labels are explicitly included. Labels are treated as numbers, i.e.,
they are right justified in the field.
A Upstream Label is 24 bits, in the same format as an MPLS label
minus the TTL field, i.e., the MSBit of the label is bit 0, the LSBit
is bit 19, the EXP bits are bits 20-22, and bit 23 is the S bit. The
replying router SHOULD fill in the EXP and S bits; the LSR receiving
the echo reply MAY choose to ignore these bits.
For explanation of rest of the fields in the Upstream TLV please
refer section 3.3 of Detecting MPLS Data Plane Failures [RFC4379].
4. Theory of Operations
4.1. Usefulness of Upstream TLV in a Bidirectional LSP sharing the same
path
The Upstream TLV MUST only be used in case of a bidirectional LSP
where Forward and Reverse Paths are same, for example, MPLS-TP Co-
routed tunnels or Multisegment Pseudo wire. In which case, the
transit nodes will know all the information required to fill both the
Downstream Mapping TLV and Upstream TLV.
Consider the following example:
+------+L0 L0+------+L1 L1+------+
| |------------>| |----------->| |
| LER1 | | LSR1 | | LER2 |
| |<------------| |<-----------| |
Saxena & Jethanandani Expires April 14, 2014 [Page 5]
Internet-Draft Upstream mapping October 2013
+------+L3 L3+------+L2 L2+------+
In the above fig, LER1 is the ingress node with forward out going
label L0 and reverse in coming label of L3. LSR1 is the transit
router with forward incoming and outgoing labels as L0 and L1
respectively and reverse incoming and outgoing labels of L2 and L3
respectively. LER2 is the egress router with forward incoming label
of L1 and reverse outgoing label of L2.
The ingress node SHOULD fill its Downstream TLV for label L0 and
Upstream TLV for label L3. When this MPLS Echo request packet
(containing the Upstream TLV and the DownStream TLV) reaches the
transit node, then the node validates both Upstream TLV for label L3
and Downstream TLV for Label L0. If the Downstream TLV for label L0
specified in the packet does not match the information the transit
node has, then the transit node sends a return code specifying
Downstream TLV mismatch. Similarly, if the Upstream TLV specified in
the packet does not match the Upstream information the transit node
has, then the transit node SHOULD send a return code of Upstream TLV
mismatch. If both, the Upstream TLV and Downstream TLV does not
match then the transit node should send a return code of Upstream and
Downstream TLV mismatch. And if both the TLVs match then the transit
node populates it's Downstream Mapping for label L1 and the Upstream
Mapping for label L2 and sends the reply back to the ingress node.
The ingress node uses this new Downstream TLV and Upstream TLV in
it's next Echo Request packet. The egress node on receiving the Echo
Request packet validates Upstream TLV and Downstream TLV. If both
the TLVs match then the egress node SHOULD send a return code of
Replying router is egress, else it SHOULD send the return code
depending on which TLV did not match.
In case a bidirectional LSP does not share the Forward and Reverse
path, for example, MPLS-TP Associated LSPs, traceroute SHOULD NOT add
Upstream TLV as part of the MPLS Echo Request. If the Forward and
Reverse LSPs are not on the same node then the transit node of the
Forward LSP won't have any information to fill the Upstream TLV.
5. Security Considerations
Security considerations, as discussed in Detecting MPLS Data Plane
Failures [RFC4379], are applicable to this document.
Saxena & Jethanandani Expires April 14, 2014 [Page 6]
Internet-Draft Upstream mapping October 2013
6. IANA Considerations
6.1. New TLV
IANA would have to assign a new TLV 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.
Upstream Detailed Mapping TLV (see Section ).
6.2. New Returns Codes
IANA needs to assign a 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 |
+-------+------------------------------------------+
| TBD | Upstream mapping mismatch |
| | |
| TBD | Downstream and Upstream mapping mismatch |
+-------+------------------------------------------+
7. Acknowledgements
We would like to thank Ashesh Mishra and Vijay D'Souza for their
feedback on this draft.
8. References
8.1. Normative References
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
Label Switched (MPLS) Data Plane Failures", RFC 4379,
February 2006.
8.2. Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for
Performing Label Switched Path Ping (LSP Ping) over MPLS
Tunnels", RFC 6424, November 2011.
Saxena & Jethanandani Expires April 14, 2014 [Page 7]
Internet-Draft Upstream mapping October 2013
[RFC6426] Gray, E., Bahadur, N., Boutros, S., and R. Aggarwal, "MPLS
On-Demand Connectivity Verification and Route Tracing",
RFC 6426, November 2011.
Authors' Addresses
Ankur Saxena
Ciena Corporation
3939 N. First Street
San Jose, CA 95134
USA
Phone: +1 (408) 904-2109
Email: ankurpsaxena@gmail.com
Mahesh Jethanandani
Ciena Corporation
3939 N. First Street
San Jose, CA 95134
USA
Phone: +1 (408) 904-2160
Email: mjethanandani@gmail.com
Saxena & Jethanandani Expires April 14, 2014 [Page 8]
