Network Working Group N. Bahadur, Ed.
Internet-Draft K. Kompella, Ed.
Intended status: Standards Track Juniper Networks, Inc.
Expires: January 2, 2008 July 1, 2007
Mechanism for performing LSP-Ping over MPLS tunnels
draft-nitinb-lsp-ping-over-mpls-tunnel-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 2, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This document describes methods for performing lsp-ping traceroute
over mpls tunnels. The techniques outlined in RFC 4379 fail to
perform correct traceroute validation and path discovery for a LSP
that goes over other mpls tunnels. This document describes new
procedures that can be used in conjunction with the standard
procedures described in RFC 4379 to trace such LSPs.
Bahadur & Kompella Expires January 2, 2008 [Page 1]
Internet-Draft LSP-Ping over MPLS tunnel July 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions used in this document . . . . . . . . . . . . 3
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Packet format . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Modification to Downstream map TLV . . . . . . . . . . . . 4
3.3. Downstream FEC Stack TLV . . . . . . . . . . . . . . . . . 4
4. Performing lsp-ping traceroute on tunnels . . . . . . . . . . 6
4.1. Transit node procedure . . . . . . . . . . . . . . . . . . 6
4.1.1. Addition of a new tunnel . . . . . . . . . . . . . . . 6
4.1.2. Transition between tunnels . . . . . . . . . . . . . . 6
4.2. Ingress node procedure . . . . . . . . . . . . . . . . . . 7
4.2.1. Handling of FEC Stack TLV . . . . . . . . . . . . . . 7
4.2.1.1. No Downstream FEC Stack TLV . . . . . . . . . . . 7
4.2.1.2. Downstream FEC Stack TLV . . . . . . . . . . . . . 7
4.2.2. Modifications to handling to EGRESS_OK responses. . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
8. Normative References . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . . . 11
Bahadur & Kompella Expires January 2, 2008 [Page 2]
Internet-Draft LSP-Ping over MPLS tunnel July 2007
1. Introduction
This documents describes methods for performing lsp-ping traceroute
over mpls tunnels. The techniques outlined in [1] outline a
traceroute mechanism that includes FEC validation and ECMP path
discovery. Those mechanisms fail in case the FEC being traced
traverses one or more mpls tunnels. This document uses the existing
definitions of [1] to define a mechanism using 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 [2].
2. Motivation
A LSP-Ping traceroute may cross multiple mpls tunnels en-route the
destination. Let us consider a simple case.
A B C D E
o -------- o -------- o --------- o --------- o
LDP RSVP RSVP LDP
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 echo-response. The
next echo request reaches router C with a LDP FEC. Node C is a pure
RSVP node and does not run LDP. So it will return back an error of
NO_MAPPING (4). It is not prudent for C to ignore FEC validation and
determine next-hop information based on incoming label stack in the
echo request. It SHOULD do the FEC validation to catch any misrouted
echo-requests. When A receives an error from C, it will be unable to
proceed with the trace and this can give the incorrect impression of
a fault in the network.
The above problem can be extended for a generic case of tunnel over
tunnel or multiple 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 can be solved if the transit routers (router B in the
above example) provide some hint or information to the ingress
regarding the start of a new tunnel.
Bahadur & Kompella Expires January 2, 2008 [Page 3]
Internet-Draft LSP-Ping over MPLS tunnel July 2007
3. Packet format
3.1. Introduction
The problem of providing more information in a lsping echo response
can be solved in multiple ways.
1. A new flag has been added to the DSMAP TLV which indicates there
is more data associated with the TLV. A new TLV (Downstream FEC
Stack TLV) has been added which can be co-related uniquely to a
DSMAP TLV in the echo response. There can be only 1 such TLV
associated with a DSMAP TLV.
3.2. Modification to Downstream map TLV
The modification described in section is based on Section 3.1,
approach 1. The downstream mapping TLV (TLV 2) defined in [1] has
been enhanced to include a new flag in the DS Flags field. The new
field definition is as below.
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|Rsvd(MBZ)|F|I|N|
+-+-+-+-+-+-+-+-+
Flag Name and Meaning
---- ----------------
F This flags should NOT be set in an echo request.
If set in an echo request, it should be ignored.
In an echo response, when this flag is set, it indicates
that a Downstream FEC Stack TLV associated with this
Downstream TLV is present in the echo response.
Figure 2: DS Flags
3.3. Downstream FEC Stack TLV
A new TLV is introduced. The TLV type is pending IANA allocation. A
router SHOULD include the the downstream FEC stack TLV when the
downstream node in the echo response will go over a tunnel (i.e. a
new FEC). The F flag in the DS-Flags fields (Figure 2) in the
corresponding downstream map TLV MUST also be set. The contents of
this TLV very similar to the contents of the Target FEC Stack TLV.
The format is as below.
Bahadur & Kompella Expires January 2, 2008 [Page 4]
Internet-Draft LSP-Ping over MPLS tunnel July 2007
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Type |Reserved (MBZ) | FEC stack length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream IP Address (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Interface Address (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. (FEC Stack) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Downstream FEC Stack TLV
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. It's usage is same as
that in the Downstream Map TLV. It MUST be the same as that
specified in the Downstream Map TLV with which this TLV is
associated.
FEC Stack Length
Length in bytes of the FEC stack.
Downstream IP Address
It MUST be the same as that specified in the Downstream Map TLV
with which this TLV is associated.
Downstream Interface Address
It MUST be the same as that specified in the Downstream Map TLV
with which this TLV is associated.
FEC Stack
The FEC Stack is a list of sub-TLVs (like the Target FEC Stack).
The number of elements is determined by looking at the sub-TLV
length fields.
Bahadur & Kompella Expires January 2, 2008 [Page 5]
Internet-Draft LSP-Ping over MPLS tunnel July 2007
4. Performing lsp-ping traceroute on tunnels
This section describes the procedures to be followed by an ingress
node and transit nodes when performing lsp-ping traceroute over mpls
tunnels.
4.1. Transit node procedure
4.1.1. Addition of a new tunnel
A transit node (Figure 1) knows when that 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 include a Downstream FEC stack TLV (Section 3.3) in the
echo-response. The transit node should construct by FEC stack by
copying the contents of target FEC stack ([1], Section 3.2) received
in the echo request and appending the FEC of the new tunnel to that.
The downstream mapping TLV (in the echo response) that corresponds to
the Downstream FEC stack TLV should have the F bit (Figure 2) set in
the DS Flags.
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. So the echo response would contain a
Downstream FEC stack TLV containing the FEC stack received in the
echo request, appended with a NIL FEC. The value of the label in the
NIL FEC MUST be set to zero.
One Downstream FEC Stack TLV SHOULD be included for each new tunnel
originating from the transit node.
4.1.2. Transition between tunnels
Consider the case in Figure 1, and B--C and C--D are 2 separate RSVP
tunnels. In such a case, based on the data in the echo request
packet, node C may or may not know that the lsp being traced is at
the end of tunnel B--C and at the start of tunnel C--D. If node B
was performing tunnel hiding (i.e. it sent a NIL FEC for the B--C
tunnel in it's echo response), then node C should NOT add a new NIL
FEC in the echo response. Addition of a NIL FEC would cause the
ingress to treat C--D as a tunnel over B--C, instead of peer tunnels.
However, in the case where the number downstream labels from C--D
increases (over the number of labels in the incoming request) due to
VPNs or some other reason, then node C MUST include a NIL FEC to
account for the extra label.
Note that if FEC hiding (via use of NIL FECs) is in use, then all
Bahadur & Kompella Expires January 2, 2008 [Page 6]
Internet-Draft LSP-Ping over MPLS tunnel July 2007
subsequent tunnels over the existing path MUST use a stack of NIL
FECs. This is to avoid intermixing of NIL FECs and non-NIL FECs.
The above applies only if the outermost FEC is the NIL FEC. i.e. if a
FEC stack contains: LDP-FEC, NIL-FEC, RSVP-FEC, then the transit node
can insert either a NIL FEC or a non-NIL FEC to represent a new
tunnel.
4.2. Ingress node procedure
It is the responsibility of an ingress node to understand tunnel
within tunnel semantics when performing a lsp traceroute. This
section describes the ingress node procedure based on the kind of
response an ingress node receives from a transit node.
4.2.1. Handling of FEC Stack TLV
4.2.1.1. No Downstream FEC Stack TLV
This would be the default behavior as described in [1]. The ingress
node MUST perform echo response processing as per the procedures in
[1].
4.2.1.2. Downstream FEC Stack TLV
If a Downstream FEC stack TLV (Section 3.3) is received in the echo
response, the ingress node SHOULD process it and perform some
validation. Each TLV must be validated as follows:
found = FALSE
for_each_downstream_map_tlv
if address_type, ip_addr and interface_addr in the
downstream_map_tlv match those in the
downstream_fec_stack_tlv
found = TRUE
if found == FALSE
ignore this downstream fec stack tlv
Downstream FEC stack TLV validation procedure
The ingress node SHOULD compare the FEC stack with the FEC stack that
it believes it is tracing. The ingress node knows this from the FEC
stack it sent in the echo request to the node that just responded.
If the FEC stack contained in the FEC data section of the TLV is the
same as the Target FEC stack sent in the echo request, then nothing
Bahadur & Kompella Expires January 2, 2008 [Page 7]
Internet-Draft LSP-Ping over MPLS tunnel July 2007
needs to be done.
An echo request contains new FEC(s) if the FEC stack in the echo
response contains the Target FEC stack ( of the echo request )
followed by more FEC(s). In such a case, the ingress node SHOULD
save the new FEC(s) and associate them with the path being traced.
The next echo request along the same path should include these FECs.
A non-NIL FEC guarantees that the next echo request along the same
path will have the DSMAP validated for IP address and Interface
address mismatch.
An echo response might contain a FEC stack that contains fewer FECs
than those sent in the echo request. If any of the missing FEC is a
non-NIL FEC, then the packet should be discarded and treated as an
error. If the missing FECs are all NIL FECs, then this is an
implicit sign that the tunnel associated with the NIL FEC has ended.
The ingress node should pop it's Target FEC stack with the same
number of NIL FECs, as missing in the echo response.
Note that an echo response containing a FEC stack exactly the same as
that sent in the echo request does not necessarily mean that the LSP
has not started traversing a new tunnel. If the bottom-most FEC in
the stack is a NIL FEC, then 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.2.2. Modifications to handling to EGRESS_OK responses.
The procedures above allow the addition of new FECs to the original
FEC being traced. Consequently, the EGRESS_OK response from a
downstream node 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
EGRESS_OK response, the ingress should check if the Target FEC sent
to the node that just responded was the base FEC that was being
traced. If it was not, then it should pop the bottom-most entry in
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 ingress receives a non-EGRESS_OK response or until
all the additional FECs added to the FEC stack have already been
popped. Using EGRESS_OK responses, an ingress can build a map of the
hierarchical LSP structure traversed by a given FEC.
Bahadur & Kompella Expires January 2, 2008 [Page 8]
Internet-Draft LSP-Ping over MPLS tunnel July 2007
5. Security Considerations
There are no new security considerations added by this document. The
security considerations discussed in [1] are applicable to this
document.
6. IANA Considerations
This document introduces a Downstream FEC Stack TLV in [1]. This has
to be assigned from the TLV type registry maintained by IANA.
7. Acknowledgements
The authors would like to thank Yakov Rekhter for his suggestions on
the draft.
8. Normative References
[1] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label
Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
Authors' Addresses
Nitin Bahadur (editor)
Juniper Networks, Inc.
1194 N. Mathilda Avenue
Sunnyvale, CA 94089
US
Phone: +1 408 745 2000
Email: nitinb@juniper.net
URI: http://www.juniper.net
Bahadur & Kompella Expires January 2, 2008 [Page 9]
Internet-Draft LSP-Ping over MPLS tunnel July 2007
Kireeti Kompella (editor)
Juniper Networks, Inc.
1194 N. Mathilda Avenue
Sunnyvale, CA 94089
US
Phone: +1 408 745 2000
Email: kireeti@juniper.net
URI: www.juniper.net
Bahadur & Kompella Expires January 2, 2008 [Page 10]
Internet-Draft LSP-Ping over MPLS tunnel July 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Bahadur & Kompella Expires January 2, 2008 [Page 11]