Network Working Group R. Zheng, Ed.
Internet-Draft L. Jin, Ed.
Intended status: Standards Track ZTE
Expires: December 18, 2012 T. Nadeau, Ed.
Juniper
G. Swallow, Ed.
Cisco
June 16, 2012
Echo Relay Reply mechanism for LSP Ping
draft-zjns-mpls-lsp-ping-relay-reply-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 December 18, 2012.
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
Zheng, et al. Expires December 18, 2012 [Page 1]
Internet-Draft MPLS LSP Ping relay reply June 2012
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions Used in This Document . . . . . . . . . . . . 3
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Echo Relay Reply message . . . . . . . . . . . . . . . . . 4
3.2. Relay Node Address Stack . . . . . . . . . . . . . . . . . 5
4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Sending an Echo Request . . . . . . . . . . . . . . . . . 6
4.2. Receiving an Echo Request . . . . . . . . . . . . . . . . 6
4.3. Sending an Echo Relay Reply . . . . . . . . . . . . . . . 7
4.4. Receiving an Echo Relay Reply . . . . . . . . . . . . . . 8
4.5. Sending an Echo Reply . . . . . . . . . . . . . . . . . . 8
4.6. Receiving an Echo Reply . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6.1. New Message Type . . . . . . . . . . . . . . . . . . . . . 9
6.2. New TLV . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Zheng, et al. Expires December 18, 2012 [Page 2]
Internet-Draft MPLS LSP Ping relay reply June 2012
1. Introduction
This draft describes LSP Ping Echo Relay Reply mechanism that can be
used to detect data plane failures in MPLS LSPs that span across
multiple domains. A new message referred to as "Echo Relay Reply
message" and a new TLV referred to as "Relay Node Address Stack TLV"
are defined in this draft.
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. Motivation
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 inter-AS scenarios, it is common of the providers to NOT
distribute the IP addresses of any of the nodes other than the ASBR.
If initiating a traceroute procedure on the ingress node PE1 of an
LSP from PE1 to PE2, P nodes in the other AS like P2 would be unable
to respond to the echo request message for the lack of IP reachable
route to PE1.
+-------+ +-------+ +------+ +------+ +------+ +------+
| | | | | | | | | | | |
| PE1 +---+ P1 +---+ ASBR1+---+ ASBR2+---+ P2 +---+ PE2 |
| | | | | | | | | | | |
+-------+ +-------+ +------+ +------+ +------+ +------+
<---------------AS1-------------><---------------AS2------------>
Zheng, et al. Expires December 18, 2012 [Page 3]
Internet-Draft MPLS LSP Ping relay reply June 2012
For the inter-area situation in Seamless MPLS architecture [ietf-
mpls-seamless], P nodes in core network would not have IP reachable
route to ANs. When tracing an LSP from AN to remote AN, the LSR1/
LSR2 node could not make a response to the echo request either, like
P2 node in the inter-AS scenario.
+-------+ +-------+ +------+ +------+
| | | | | | | |
+--+ 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
response from the replying LSR to be relayed back to the initiator.
The replying LSR would send the response to a relay node indicated by
the Relay Node Address Stack TLV, and the response would be relayed
to the next relay node, till to the initiator.
3. Extensions
RFC4379 describes the basic MPLS LSP Ping mechanism, which defines
two message types. This draft defines a new message, Echo Relay
Reply message. This new message is used to replace Echo Reply
message which is sent from the replying LSR to a relay node or from a
relay node to another relay node.
In addition, a new TLV named Relay Node Address Stack TLV is defined
in this draft, to carry the IP addresses of the possible relay nodes
for the replying LSR.
3.1. Echo Relay Reply message
The echo relay reply message is a UDP packet, and the UDP payload has
the same format with echo request/reply message. A new message type
is requested from IANA.
Zheng, et al. Expires December 18, 2012 [Page 4]
Internet-Draft MPLS LSP Ping relay reply June 2012
New Message Type:
Value Meaning
----- -------
TBD MPLS echo relay reply
3.2. Relay Node Address Stack
The Relay Node Address Stack TLV MUST be carried in the echo request,
echo reply and echo relay 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initiator Source Port | Number of Relayed Addresses |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Stack of Relayed Addresses ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Relay Node Address Stack TLV
- Type: to be assigned by IANA.
- Length: The Length of the Value field in octets.
- Initiator Source Port: The port that the initiator sends the echo
request message, and also the port that expected to receive the
echo reply message.
- Number of Relayed Addresses: An integer indicating the number of
relayed addresses in the stack.
- Stack of Relayed Addresses: A list of relay node addresses.
The format of each relay node address is as below:
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 | Address Length| Reserved |K|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Relayed Address (0, 4, or 16 octects) ~
Zheng, et al. Expires December 18, 2012 [Page 5]
Internet-Draft MPLS LSP Ping relay reply June 2012
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type# Address Type Address Length
---- ------------ ------------
0 Unspecified 0
1 IPv4 4
2 IPv6 16
Reserved: This field is reserved for future use and MUST be set to
zero.
K bit:
If the K bit is set to 1, then this sub-TLV SHOULD be kept in Relay
Node Address Stack, SHOULD not be deleted in compress process of
section 4.2. The K bit may be set by ASBRs which address would be
kept in the stack if necessary.
If the K bit is set to 0, then this sub-TLV SHOULD be processed
normally according to section 4.2.
Relayed Address: This field specifies the node address, either IPv4
or IPv6.
4. Procedures
4.1. Sending an Echo Request
The procedures described in Section 4.3 of RFC4379 apply here. In
addition, An Relay Node Address Stack TLV MUST be carried in the echo
request message.
When the echo request is first sent by initiator, a Relay Node
Address Stack TLV with the initiator address in the stack and its
source port MUST be included.
For the subsequent echo request messages, the initiator would copy
the Relay Node Address Stack TLV from the received echo reply
message.
4.2. Receiving an Echo Request
In addition to the processes in Section 4.4 of RFC4379, the
procedures of the Relay Node Address Stack TLV are defined here.
Upon receiving a Relay Node Address Stack TLV of the echo request
Zheng, et al. Expires December 18, 2012 [Page 6]
Internet-Draft MPLS LSP Ping relay reply June 2012
message, the receiver would check the addresses of the stack in
sequence from top to bottom, to find out the first public routable IP
address. Those address entries behind of the first routable IP
address in the address list with K bit set to 0 would be deleted, and
the address entry of the replying LSR would be added at the bottom of
the stack. Those address entries with K bit set to 1 would be kept
in the stack. The updated Relay Node Address Stack TLV would be
carried in the response message.
If the replying LSR wishes to hide its routable address information,
the address entry added in the stack would be a blank entry with
Address Type set to Unspecified. The blank address entry in the
receiving echo request would be treated as an unroutable address
entry.
If the first routable IP address is the first address in the stack,
the replying LSR would respond an echo reply message to the
initiator.
If the first routable IP address is of an intermediate node, other
than the first address in the stack, the replying LSR would send an
echo relay reply instead of an echo reply in response.
4.3. Sending an Echo Relay Reply
The echo relay reply is sent in two cases:
1. When the replying LSR received an echo request with the initiator
IP address in the Relay Node Address Stack TLV is IP unroutable, the
replying LSR would send an echo relay reply message to the first
routable intermediate node. The encapsulation processing of echo
relay reply is the same with the procedure of the echo reply
described in Section 4.5 of RFC4379, except the destination IP
address and the destination UDP port of the message part. The
destination IP address of the echo relay reply is set to the first
routable IP address from the Relay Node Address Stack TLV, and the
destination UDP port is set to 3503.
2. When the intermediate relay node received an echo relay reply
with the initiator IP address in the Relay Node Address Stack TLV is
IP unroutable, the intermediate relay node would send the echo relay
reply to the next relay node with the content of the UDP packet
unchanged. The destination IP address of the echo relay reply is set
to the first routable IP address from the Relay Node Address Stack
TLV. Both the source and destination UDP port should be 3503.
Zheng, et al. Expires December 18, 2012 [Page 7]
Internet-Draft MPLS LSP Ping relay reply June 2012
4.4. Receiving an Echo Relay Reply
Upon receiving an echo relay reply message with its address as the
destination address in the IP header, the relay node should check the
address items in Relay Node Address Stack TLV in sequence and find
the first routable node address.
If the first routable address is the top one of the address list,
i.e., the initiator address, the relay node should send an echo reply
message to the initiator containing the same payload with the echo
relay reply message received.
If the first routable address is not the top one of the address list,
i.e., another intermediate relay node, the relay node should send an
echo relay reply message to this relay node with the payload
unchanged.
4.5. Sending an Echo Reply
The echo relay reply is sent in two cases:
1. When the replying LSR received an echo request with the initiator
IP address in the Relay Node Address Stack TLV is IP routable, the
replying LSR would send an echo reply to the initiator. The
processing of echo relay reply is the same with the procedure of the
echo reply described in Section 4.5 of RFC4379.
2. When the intermediate relay node LSR received an echo relay reply
with the initiator IP address in the Relay Node Address Stack TLV is
IP routable, the intermediate relay node would send the echo reply to
the initiator with the payload no changes other than the Message Type
field. The destination IP address of the echo reply is set to the
initiator IP address, and the destination UDP port would be copied
from the Initiator Source Port field of the Relay Node Address Stack
TLV. The source UDP port should be 3503.
4.6. Receiving an Echo Reply
In addition to the processes in Section 4.6 of RFC4379, the initiator
would copy the Relay Node Address Stack TLV received in the echo
reply to the next echo request.
5. Security Considerations
In addition to the Security Consideration from [RFC4379], to avoid
potential Denial-of-service attack, it is RECOMMENED that
implementations regulate the LSP Ping traffic going to the control
Zheng, et al. Expires December 18, 2012 [Page 8]
Internet-Draft MPLS LSP Ping relay reply June 2012
plane. A rate limiter SHOULD be applied to UDP port 3503 of the
intermediate node.
The node which acts as a relay node SHOULD validate the relay reply
against a set of valid source addresses. An implementation SHOULD
provide such filtering capabilities.
If an operator wants to obscure their nodes, then a blank entry may
be used in the address stack.
6. IANA Considerations
IANA is requested to assign one new Message Type and one new TLV
6.1. New Message Type
New Message Type:
Value Meaning
----- -------
TBD MPLS echo relay reply
6.2. New TLV
New TLV: Routable Relay Node Address TLV
Type Meaning
---- --------
TBD Relay Node Address Stack TLV
7. Acknowledgement
The authors would like to thank Carlos Pignataro, Xinwen Jiao and
Manuel Paul for their valuable comments and discussions.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4377] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S.
Matsushima, "Operations and Management (OAM) Requirements
for Multi-Protocol Label Switched (MPLS) Networks",
RFC 4377, February 2006.
Zheng, et al. Expires December 18, 2012 [Page 9]
Internet-Draft MPLS LSP Ping relay reply June 2012
[RFC4378] Allan, D. and T. Nadeau, "A Framework for Multi-Protocol
Label Switching (MPLS) Operations and Management (OAM)",
RFC 4378, February 2006.
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
Label Switched (MPLS) Data Plane Failures", RFC 4379,
February 2006.
[RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for
Performing Label Switched Path Ping (LSP Ping) over MPLS
Tunnels", RFC 6424, November 2011.
[RFC6425] Saxena, S., Swallow, G., Ali, Z., Farrel, A., Yasukawa,
S., and T. Nadeau, "Detecting Data-Plane Failures in
Point-to-Multipoint MPLS - Extensions to LSP Ping",
RFC 6425, November 2011.
8.2. Informative References
[ietf-mpls-seamless]
Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz,
M. and D. Steinberg, "Seamless MPLS Architecture",
draft-ietf-mpls-seamless-mpls-00 , May 2011.
Authors' Addresses
Ryan Zheng (editor)
ZTE
50, Ruanjian Avenue
Nanjing, 210012, China
Email: zheng.zhi@zte.com.cn
Lizhong Jin (editor)
ZTE
889, Bibo Road
Shanghai, 201203, China
Email: lizhong.jin@zte.com.cn
Thomas Nadeau (editor)
Juniper
Email: tnadeau@juniper.net
Zheng, et al. Expires December 18, 2012 [Page 10]
Internet-Draft MPLS LSP Ping relay reply June 2012
George Swallow (editor)
Cisco
300 Beaver Brook Road
Boxborough , MASSACHUSETTS 01719, USA
Email: swallow@cisco.com
Zheng, et al. Expires December 18, 2012 [Page 11]