One document matched: draft-ali-ccamp-gmpls-lsp-ping-traceroute-00.txt
CCAMP Working Group Z. Ali (Cisco Systems, Inc.)
Internet Draft T. Otani(KDDI R&D Laboratories, Inc.)
Intended status: Standards Track
Expires: May 2008
Ping and Traceroute for GMPLS LSPs in Non-Packet Switched
Networks
draft-ali-ccamp-gmpls-lsp-ping-traceroute-00.txt
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.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
"Detecting Multi-Protocol Label Switched (MPLS) Data Plane
Failures," RFC4379, describes procedures for ping and
traceroute for LSPs that traverse a Packet Switch Capable
(PSC) network. These procedures are known as Label Switched
Path Ping (LSP Ping).
Z. Ali Expires May 11, 2008 [Page 1]
Internet-Draft draft-ali-ccamp-gmpls-LSP-ping-traceroute-00.txt
An important implication of using non-PSC nodes in a
Generalized MPLS (GMPLS) network is that the LSP Ping solution
described in RFC4379 is not applicable to LSPs traversing a
non-PSC network. Another important feature introduced by GMPLS
is the potential for data and control plane separation with
the consequence that LSP Ping procedures for ping and
traceroute that rely on in-band propagation of messages cannot
be applied.
This document describes mechanisms that can be used to detect
and isolate data plane failures in non-PSC GMPLS LSPs. The
document also proposes a method to traceroute a GMPLS LSP in
PSC or non-PSC networks where the data and control planes are
separated. The proposed solutions are based on the Link
Management Protocol (LMP) described in RFC4204 and on MPLS LSP
Ping [RFC4379].
The document is particularly applicable to data plane
technologies where the data plane does not otherwise provide
the OAM functions (e.g., pre-OTH photonic cross-connects).
Conventions used in this document
In examples, "C:" and "S:" indicate lines sent by the client
and server respectively.
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 RFC-2119 [RFC2119].
Table of Contents
1. Introduction..............................................3
2. Connectivity Verification and Isolating Faults............4
2.1. Control Channel Management...........................5
2.2. LSP Verification Procedure...........................6
3. Fault Isolation...........................................7
4. Tracerouting..............................................7
5. Security Considerations...................................9
6. IANA Considerations.......................................9
7. Acknowledgments...........................................9
8. References...............................................10
8.1. Normative References................................10
8.2. Informative References..............................10
9. Author's Addresses.......................................10
Z. Ali, et al Expires May 11, 2008 [Page 2]
Internet-Draft draft-ali-ccamp-gmpls-LSP-ping-traceroute-00.txt
10. Intellectual Property Statement.........................10
11. Copyright Statement.....................................11
1. Introduction
When a Generalized Multiprotocol Label Switching (GMPLS) label
Switched Path (LSP) fails to deliver user traffic, the failure
cannot always be detected by the GMPLS control plane. There is
a need to provide a tool that enables users to detect such
traffic "black holes" or misrouting within a reasonable period
of time, and a mechanism to isolate faults [GMPLS-OAM-REQ].
Similarly, the ability to trace the route of GMPLS LSPs in
networks where data and control planes are separated is a
requirement [GMPLS-OAM-REQ]. This document provides solution
to these requirements.
[RFC4379] describes procedures for LSP Ping for LSPs with
Packet Switch Capable (PSC) endpoints and transit switching
capabilities. However, the LSP Ping solution is not applicable
to LSPs crossing or terminating at non-PSC devices. This is
because the solution described in [RFC4379] requires all
transit and end point nodes along the LSP path to be able to
intercept the MPLS OAM (Operation and Maintenance) packets
traveling in the data plane and identify the target Forwarding
Equivalence Class (FEC) Stack being tested. Such operations
cannot be realized at nodes that are non PSC-capable.
Moreover, the LSP Ping mechanism described in [RFC4379] may be
inadequate even when the end points of the GMPLS LSP are PSC-
capable. This is because the GMPLS LSP may appear as a single
hop for procedures described in [RFC4379]. In such cases,
mechanisms in [RFC4379] are able to detect data plane failure
in the GMPLS LSP but are still not able to isolate failures in
underlying switching layers. Similarly, in this scenario, the
GMPLS LSP appears as a single hop during traceroute
procedures. This document describes a mechanism that can be
used to detect and isolate data plane failures in GMPLS LSPs
with non-PSC transit switching capability.
As mentioned above, the Echo Request [RFC4379] follows the
same path as data packets, i.e., they are not control plane
messages. This is also a limitation when tracing a GMPLS LSP
with non-PSC transit nodes. This is because non-PSC devices
are incapable of intercepting the MPLS echo request packets,
and hence, cannot process these packets, e.g., check or update
TTL values needed for traceroute functionality. A consequence
of this is that traceroute for GMPLS LSPs has to be performed
Z. Ali, et al Expires May 11, 2008 [Page 3]
Internet-Draft draft-ali-ccamp-gmpls-LSP-ping-traceroute-00.txt
out-of-band in the control network, probing entities that
control the non-PSC devices (e.g. optical cross-connects).
This draft also proposes extensions to LSP traceroute
procedures that can be implemented in GMPLS networks with data
and control plane separation.
The proposed solutions are based on the Link Management
Protocol (LMP) [RFC4204] and Multiprotocol Label Switching
(MPLS) Operations and Management (OAM) solutions [RFC4379]. In
the following sections, we outline how existing LMP and MPLS
OAM procedures needs to be modified to provide ping and
tracerouting functionality in GMPLS networks. Recall the scope
of this draft is cases where data plane does not provide the
OAM functions addressed by this draft (e.g., pre-OTH photonic
cross-connects). Use of OAM functionality provided by the data
planes is RECOMMENDED and procedures described in this draft
are only assumed to be applied when OAM mechanisms are not
supported by the data plane or are deficient.
2. Connectivity Verification and Isolating Faults
LMP fault isolation mechanism [RFC4204] can be used to detect
and isolate failures along a GMPLS LSP. The requirement is to
be able to check the health of an LSP before carrying traffic
over it. Consequently, the ability to use LMP fault isolation
mechanism for this purpose largely depends on the transport
technology. Specifically, in technologies where a signal is
(constantly) carried even without data, LMP fault isolation
procedure can be applied as soon as LSP is setup. This draft
addresses technologies where this is not possible (e.g., pre-
OTH cross-connects) by extending the use LMP "Test" message
for connectivity verification and fault isolation. For this
purpose, the draft proposes an extended LMP model as shown
below.
+------+ +------+ +------+ +------+
| | ----- | | ===== | | ----- | |
| OXC1 | ===== | OXC2 | ----- | OXC3 | ----- | OXC4 |
| | ----- | | ----- | | ===== | |
+------+ +------+ +------+ +------+
^ ^ ^ ^ ^ ^ ^ ^
Z. Ali, et al Expires May 11, 2008 [Page 4]
Internet-Draft draft-ali-ccamp-gmpls-LSP-ping-traceroute-00.txt
| | | | | | | |
| +----LMP1----+ +----LMP2---+ +-----LMP3----+ |
| |
+----------------------LMP4----------------------+
Figure 1 Extended LMP Model.
In this model, the Ingress and Egress nodes of the LSP under
verification may establish and maintain LMP session. The nodes
continue to maintain hop-by-hop LMP sessions to build traffic
engineering (TE) links for GMPLS signaling and routing, as
described in [RFC4204]. For example in Figure 1, OXC1-OXC2
(LMP1), OXC2-OXC3 (LMP2), and OXC3-OXC4 (LMP3) LMP sessions
are used to build traffic-engineering (TE) links for GMPLS
signaling and routing, while the LMP session between OXC1-OXC4
(LMP4) is used to monitor health of GMPLS LSP(s) with OXC1 and
OXC4 as end-points. Existing signaling mechanism (e.g.,
LSP_TUNNEL_INTERFACE_ID object for RSVP-TE signaling
[RFC3477], [) are used to discover remote link properties,
i.e., the LMP session between LSP end-point nodes is only used
for OAM purposes.
Once an LMP session between LSP end-point nodes comes up, Link
connectivity verification can be used to perform LSP
connectivity verification. This is done by sending Test
messages over the GMPLS LSP and TestStatus messages back over
the control channel. For this purpose, LMP connectivity
verification procedure as described in [RFC4204] is used. It
is important to note LMP link verification procedure [RFC4204]
applies to equally to PSC and non-PSC TE links. Similarly, in
order to send Test messages over the GMPLS LSP, the end-point
of the LSP does not have to be PSC.
2.1. Control Channel Management
The control channel management for LSP ingress-node-to-egress-
node is the same as described in [RFC4204]. To distinguish
between an LSP ingress-node-to-egress-node LMP session and a
peer node-to-peer node LMP session, or LMP-WDM session, a new
bit for LMP-WDM_CONFIG object [RFC4209] is defined as follows:
Class = 6, C-Type = 2, LMP-WDM_CONFIG [RFC4209].
0 1 2
3
Z. Ali, et al Expires May 11, 2008 [Page 5]
Internet-Draft draft-ali-ccamp-gmpls-LSP-ping-traceroute-00.txt
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+-+-+
|W|O|L| (Reserved)
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+-+-+
The Reserved field should be sent as zero and ignored on
receipt. W and O bits are defined in [RFC4209]. The draft
defined the "L" bit, where "L" stands for LMP peering for
"LSP".
L : 1 bit
This bit indicates that the peer node wants to establish an
LMP session to test LSP(s). The L bit is defined to
distinguish LSP-ingress-node-to-LSP-egress-node LMP sessions
from other types of LMP sessions as defined in [RFC4204]and
[RFC4209].
To establish an ingress-node-to-egress-node LMP session, the
Ingress node sets "L" bit in the LMP-WDM_CONFIG message and
sends it to the peering Egress node for LSP(s) under test. The
Egress nodes can also initiate LMP session by sending LMP-
WDM_CONFIG message with L = 1. [RFC4209] requires a node that
does not support LMP-WDM_CONFIG message to MUST reply with a
ConfigNack message. If a node supports LMP-WDM_CONFIG message
but does not support L bit, it MUST reply to the LMP-
WDM_CONFIG message with a ConfigNack message. The rest of the
details for control channel management follow [RFC4204].
2.2. LSP Verification Procedure
The link verification procedure described in [RFC4204] has
been adapted for LSP verification. Specifically, once a
control channel has been established between the ingress and
egress nodes of an LSP, LSP connectivity can be verified by
exchanging Test messages between nodes along the GMPLS LSP's
path. Since the LSP's health can be tested along the
forwarding transmit path, both endpoints nodes can
(independently and simultaneously) initiate the exchange of
Test messages in each direction to test for the health of
bidirectional LSPs.
Z. Ali, et al Expires May 11, 2008 [Page 6]
Internet-Draft draft-ali-ccamp-gmpls-LSP-ping-traceroute-00.txt
To initiate the link verification procedure, the Ingress
(Egress) node MUST send a BeginVerify message over a control
channel with IP address of the destination (source) node of
the LSP. To limit the scope of LSP Verification to a
particular LSP, LSP-id is used in LOCAL_LINK_ID or
REMOTE_LINK_ID fields of the LMP message exchanges during
verification. If the LINK_ID field is zero, the verification
can span multiple LSPs between the set of Ingress/Egress nodes
involved in the verification process. The rest of the details
for LSP verification follow the LMP link verification
procedure [RFC4204].
3. Fault Isolation
If LSP verification fails, the LMP fault isolation procedure
[RFC4204] can be applied. For this purpose, the Ingress
(Egress) node initiating the LSP fault localization procedure
starts the LSP verification procedure by setting
VerifyInterval to a time interval large enough to perform
fault isolation procedure. Actual selection of the interval is
a local decision, but the requirement is that LMP link
verification procedure should not time out before the fault is
localized. The node initiating the LSP fault localization
procedure then starts sending the Test message over the LSP
under test. This enables a downstream node (downstream in
terms Test message flow) to detect data link failure where the
LSP may be broken. This downstream node then sends a
ChannelStatus message to its upstream neighbor indicating that
a failure has been detected. The rest of details for the LSP
fault isolation procedure follows LMP fault isolation
procedure [RFC4204].
4. Tracerouting
As mentioned above, one of the consequences of transparent
nature of optical cross-connects is that traceroute for GMPLS
LSPs has to be performed out-of-band in the control network,
probing entities that control the non-PSC devices (e.g.,
optical cross-connects). This also requires control entities
to be in-sync with the forwarding states of the device. How
control entities achieves this goal is beyond the scope of
this document.
When the route of a GMPLS LSP is traced in the control
network, MPLS Echo Request packets are dispatched toward each
transit LSR of the LSP while including the LSP's tested FEC,
and setting the appropriate value of the TTL in the MPLS echo
Z. Ali, et al Expires May 11, 2008 [Page 7]
Internet-Draft draft-ali-ccamp-gmpls-LSP-ping-traceroute-00.txt
request. The main issue with probing GMPLS flows in the
control plane is that the control network topology is entirely
independent of the data network topology; For example, an MPLS
echo request probe packet may travel multiple hops in the
control plane to reach an LSR that is only 1 hop away in the
data plane. This draft proposes use of GRE encapsulation of
MPLS Echo request messages and a method to force Echo requests
to follow the data plane's topology, while flowing through the
control network. Other tunneling techniques, like IP-in-IP are
equally applicable.
The sender of the MPLS echo packets encapsulate the IP/UDP
MPLS echo request packet using GRE. The GRE packet can then be
routed inside the control network to the next hop transit LSR
in the control plane. The receiver control entity decapsulates
the GRE header and then processes the echo request by looking
up the FEC for the data LSP and sending the echo reply with
the appropriate downstream mappings.
Both Ingress and Egress LSRs can start LSP tracing operations.
The Ingress (Egress) LSR follows the following steps:
1. The Ingress (Egress) LSR finds optical nodes that are one
hop away in data plane. The exact details on how Ingress
(Egress) LSR finds optical nodes that are one hop away in
data plane is beyond the scope of this document but using
the control plane state of the LSP under trace, the ingress
LSP can determine the IP address of the control plane node
that is one hop downstream (upstream), even when RRO is not
used.
2. The Ingress LSR sends MPLS echo Request packet with TTL=1
and encapsulates it using GRE to the node that it finds in
the last steps.
3. When the control entities at the optical node that is
assumed to be one hop away in data plane, receives the MPLS
echo request message from the ingress (Egress) LSR via GRE
tunnel, it examines the tested FEC contained in the MPLS
Echo request, and sends an echo reply back to the ingress
(Egress) LSR if it has a crossconnect for the FEC under
test. If the receiving control node has a crossconnect for
the FEC under test, the node also returns the control plane
address of the next hop node (obtained in fashion mentioned
in step 1). This will allow the ingress to tunnel to the
next control plane node. Details for how MPLS Echo response
Z. Ali, et al Expires May 11, 2008 [Page 8]
Internet-Draft draft-ali-ccamp-gmpls-LSP-ping-traceroute-00.txt
needs to be modified is to be added in a later version of
the document.
4. Upon receiving the Echo reply, Ingress (Egress) nodes
prepares a Echo Request packet with TTL = 1 and encapsulates
it using GRE to the node that it learned via Echo reply in
step 3.
5. The Ingress (Egress) LSR repeats the same procedure for
nodes that it learns from step 4 until it learns destination
(source) node and repeats step 4 for destination (source)
node.
5. Security Considerations
Security considerations and requirements form [RFC4204] and
[RFC4379] apply equally to this document. Furthermore, there
are some additional security considerations that may be
induced by extended LMP model proposed by this draft. These
security considerations will be added in a later version of
the draft.
6. IANA Considerations
TBA
7. Acknowledgments
The authors would like to acknowledge comments from Adrian
Farrel , Tarek Saad, and David Ward.
Z. Ali, et al Expires May 11, 2008 [Page 9]
Internet-Draft draft-ali-ccamp-gmpls-LSP-ping-traceroute-00.txt
8. References
8.1. Normative References
[RFC4204] "Link Management Protocol (LMP)", J. Lang, et al.,
http://tools.ietf.org/html/rfc4204.
[RFC4379] "Detecting Multi-Protocol Label Switched (MPLS) Data
Plane Failures", K. Kompella, G. Swallow, et al.,
http://tools.ietf.org/html/rfc4379.
[GMPLS-OAM-REQ] "OAM Requirements for Generalized Multi-
Protocol Label Switching (GMPLS) Networks", T. Otani, et al.,
draft-ietf-ccamp-gmpls-oam-requirements-00.txt.
[RFC4209] "Link Management Protocol (LMP) for Dense Wavelength
Division Multiplexing (DWDM) Optical Line Systems", J. Lang,
et al., http://tools.ietf.org/html/rfc4209.
[RFC2119] "Key words for use in RFCs to Indicate Requirement
Levels", S. Bradner, http://tools.ietf.org/html/rfc2119.
8.2. Informative References
[RFC3477] "Signalling Unnumbered Links in Resource ReSerVation
Protocol - Traffic Engineering (RSVP-TE)", K. Kompella, Y.
Rekhter, et al, http://tools.ietf.org/html/rfc3477.
9. Author's Addresses
Zafar Ali
Cisco Systems, Inc.
Email: zali@cisco.com
Tomohiro Otani
KDDI R&D Laboratories, Inc.
Email: otani@kddilabs.jp
10. Intellectual Property Statement
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
Z. Ali, et al Expires May 11, 2008 [Page 10]
Internet-Draft draft-ali-ccamp-gmpls-LSP-ping-traceroute-00.txt
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.
11. 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.
Z. Ali, et al Expires May 11, 2008 [Page 11]
| PAFTECH AB 2003-2026 | 2026-04-24 05:53:30 |