Internet DRAFT - draft-zj-mpls-lsp-ping-reply-relay
draft-zj-mpls-lsp-ping-reply-relay
Network Working Group R. Zheng
Internet-Draft L. Jin
Intended status: Standards Track ZTE
Expires: April 25, 2012
October 23, 2011
LSP Ping extensions for echo reply relay
draft-zj-mpls-lsp-ping-reply-relay-00
Abstract
[RFC4379] describes the LSP Ping mechanism to detect data plane
failures. In some deployment scenario for the LSP traceroute, a
replying LSR may not have the available route to the initiator, and
the echo reply message sent to the initiator would be discarded.
Thus, the basic idea of traceroute procedure to localize fault could
not be achieved. This document describes extensions to LSP Ping
mechanism to enable the replying LSR to have the capability to relay
the echo reply by a set of routable intermediate nodes to the
initiator.
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 25, 2012.
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
Zheng, et al. Expires April 25, 2012 [Page 1]
Internet-Draft MPLS LSP Ping reply relay October 2011
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions Used in This Document . . . . . . . . . . . . . 4
2. Routable Relay Node Address TLV . . . . . . . . . . . . . . . . 4
3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. LSP Ping Example . . . . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Zheng, et al. Expires April 25, 2012 [Page 2]
Internet-Draft MPLS LSP Ping reply relay October 2011
1. Introduction
LSP Ping is an efficient OAM mechanism to detect data plane failures
and localize faults. The basic LSP Ping mechanism has been described
in [RFC4379]. In traceroute mode of LSP Ping procedure, the echo
request message is sent to the control plane of each transit LSR, and
an echo reply massage with proper information are required to send to
the initiator at each transit LSR. Then the LSP fault could be
localized exactly, and an accurate LSP topology could also be built.
The echo reply would normally be sent back to the initiator via an
IPv4/IPv6 UDP packet. The basic requirement is that the replying LSR
has reachable IP route to the initiator. However, in some network
deployment, the requirement could not be met because of the route
control policy. For example, considering the inter-area situation in
Seamless MPLS architecture [ietf-mpls-seamless], LSR1/LSR2 nodes in
core network would not have IP reachable route to ANs. If tracing an
LSP from AN to remote AN, the LSR1/LSR2 node would be unable to
respond to the echo request message for the lack of IP reachable
route to AN.
+-------+ +-------+ +------+ +------+
| | | | | | | |
+--+ AGN11 +---+ AGN21 +---+ ABR1 +---+ LSR1 +--> to AGN
/ | | /| | | | | |
+----+/ +-------+\/ +-------+ +------+ /+------+
| AN | /\ \/
+----+\ +-------+ \+-------+ +------+/\ +------+
\ | | | | | | \| |
+--+ AGN12 +---+ AGN22 +---+ ABR2 +---+ LSR2 +--> to AGN
| | | | | | | |
+-------+ +-------+ +------+ +------+
static route ISIS L1 LDP ISIS L2 LDP
<-Access-><--Aggregation Domain--><---------Core--------->
This draft describes extensions to LSP Ping mechanism to enable the
echo reply message to be relayed back to the initiator. The replying
LSR would send the echo reply message to a routable relayed node
indicated by the Routable Relay Node Address TLV, and the echo reply
would be relayed to the next relay node, till to the initiator.
Note: [I-D. ietf-mpls-interas-lspping-00] describes an echo reply
relayed mechanism for inter-AS scenario, by using a dedicated ASBR
stack list. Unfortunately, this mechanism could not be applied in
Zheng, et al. Expires April 25, 2012 [Page 3]
Internet-Draft MPLS LSP Ping reply relay October 2011
inter-area scenario. The current mechanism described in this draft
is only for inter-area scenario.
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. Routable Relay Node Address TLV
The Routable Relay Node Address TLV MUST be carried in the echo
request and echo reply messages if the echo reply relayed mechanism
described in this draft is required.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Node 1 IP Address (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Node n IP Address (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Routable Relay Node Address TLV
- Type: to be assigned by IANA.
- Length: The Length of the Value field in octets.
- Address Type
The Address Type indicates the routable relay node address type. The
routable relay node IP address length is determined based on the
Address Type.
Type Address Type Node Address length
---- -------------- ----------------------
1 IPv4 4
2 IPv6 16
Zheng, et al. Expires April 25, 2012 [Page 4]
Internet-Draft MPLS LSP Ping reply relay October 2011
- Node 1 IP Address: The IP Address of the first node that adds its
address in this TLV.
- Node n IP Address: The IP Address of the last node that adds its
address in this TLV.
3. Procedures
When tracing an LSP with outmost label TTL=1, a Routable Relay Node
Address TLV with the first address item of the initiator address
should be included in the echo request.
Upon receiving an echo request message, the receiver checks the
address list in the Routable Relay Node Address TLV from node 1 to n
IP address. Until finds the first routable node address, sets this
node address as the destination address of the echo reply message.
The receiver deletes all the node IP address items behind of the
first routable one in the address list, and adds its own address as
the last address item in the Routable Relay Node Address TLV. The
updated Routable Relay Node Address TLV should be carried in the echo
reply message.
Upon receiving an echo reply message with its address as the
destination address in the IP header, the receiver should check the
address items in Routable Relay Node Address TLV in sequence to find
the next relay node address. If its own address is node n IP
address, then the next relay node address is node (n-1) IP address.
The receiver should then send the echo reply to the next relay node
with the Routable Relay Node Address Stack TLV unchanged. The next
relay node may be an intermediate node or the initiator.
As relayed by intermediate nodes, the echo reply will finally be
transmitted to the initiator. The initiator will copy the Routable
Relay Node Address TLV from the echo reply into the next echo request
message.
Those nodes do not understand or support the Routable Relay Node
Address TLV, SHOULD ignore and pass it unchanged.
4. LSP Ping Example
Considering the inter-area scenario of Seamless MPLS architecture
below,
Zheng, et al. Expires April 25, 2012 [Page 5]
Internet-Draft MPLS LSP Ping reply relay October 2011
+-------+ +-------+ +------+ +------+
| | | | | | | |
#### AGN11 ##### AGN21 ##### ABR1 ##### LSR1 ###> to AGN
# | | /| | | | | |
+----+# +-------+\/ +-------+ +------+ /+------+
| AN | /\ \/
+----+\ +-------+ \+-------+ +------+/\ +------+
\ | | | | | | \| |
+--+ AGN12 +---+ AGN22 +---+ ABR2 +---+ LSR2 +--> to AGN
| | | | | | | |
+-------+ +-------+ +------+ +------+
static route ISIS L1 LDP ISIS L2 LDP
<-Access-><--Aggregation Domain--><---------Core--------->
Supposing the active LSP from AN to remote AN goes through AGN11,
AGN21, ABR1, LSR1 and the following nodes. When performing LSP
traceroute on the LSP the first echo request sent by AN with outmost
label TTL=1, contains the Routable Relay Node Address TLV with the
only address of AN.
After processed by AGN11, AGN11 address will be added in the Routable
Relay Node Address list following AN1 address in the echo reply.
AN1 copies the Routable Relay Node Address TLV into the next echo
request when receiving the echo reply.
Upon receiving the echo request, AGN21 checks the address list in the
Routable Relay Node Address TLV in sequence, and finds out that AN1
address is routable. Then deletes AGN11 address, and adds its own
address following AN1 address. As a result, there would be AN1
address followed by AGN21 address in the Routable Relay Node Address
TLV of the echo reply sent by AGN21.
For echo request with outmost label TTL=3, similarly with the
procedures on AGN21, the Routable Relay Node Address TLV sent by ABR1
in the echo reply will include two address items with both AN1 and
ABR1 address.
Then AN1 sends echo request with outmost label TTL=4, containing the
Routable Relay Node Address TLV copied from the received echo reply
message. Upon receiving the echo request message, LSR1 checks the
address list in the Routable Relay Node Address TLV in sequence, and
finds out that AN1 address is IP route unreachable, and ABR1 address
is the first routable one in the Routable Relay Node Address TLV.
LSR1 adds its address as the last address item following ABR1 address
in the Routable Relay Node Address TLV, sets ABR1 address as the
Zheng, et al. Expires April 25, 2012 [Page 6]
Internet-Draft MPLS LSP Ping reply relay October 2011
destination address of the echo reply, and sends the echo reply to
ABR1.
Upon receiving the echo request message from LSR1, ABR1 checks the
address list in the Routable Relay Node Address TLV in sequence, and
finds out that AN1 address is the one just before its address. Then
ABR1 sends the echo reply to AN1 with the Routable Relay Node Address
TLV unchanged.
The echo reply from the replying node which has no reachable route to
the initiator is finally transmitted to the initiator by multiple
relay nodes.
5. Security Considerations
TBD
6. IANA Considerations
TBD
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
Label Switched (MPLS) Data Plane Failures", RFC 4379,
February 2006.
7.2. Informative References
[I-D.ietf-mpls-interas-lspping-00]
Nadeau, T.and G. Swallow, "Detecting MPLS Data Plane
Failures in Inter-AS and inter-provider Scenarios",
draft-ietf-mpls-interas-lspping-00(expired) , March 2007.
[I-D.ietf-mpls-seamless-mpls-00]
Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz,
M. and D. Steinberg, "Seamless MPLS Architecture",
draft-ietf-mpls-seamless-mpls-00 , May 2011.
Zheng, et al. Expires April 25, 2012 [Page 7]
Internet-Draft MPLS LSP Ping reply relay October 2011
Authors and contributors' Addresses
Ryan Zheng
ZTE Corporation
50, Ruanjian Avenue
Nanjing, 210012, China
Email: zheng.zhi@zte.com.cn
Lizhong Jin
ZTE Corporation
889, Bibo Road
Shanghai, 201203, China
Email: lizhong.jin@zte.com.cn
Manuel Paul
Deutsche Telekom
Goslarer Ufer 35
10589 Berlin, Germany
Email: manuel.paul@telekom.de
Zheng, et al. Expires April 25, 2012 [Page 8]
