Internet DRAFT - draft-smiler-mpls-tp-static-lsp-config-check
draft-smiler-mpls-tp-static-lsp-config-check
INTERNET-DRAFT Kingston Smiler Selvaraj
Intended Status: Standards Track Ip Infusion
Expires: March 05, 2013 L. Jin
ZTE
Sep 06, 2012
Static MPLS-TP LSP configuration checking using Generic Associated
Channel (G-ACh) Advertisement Protocol
draft-smiler-mpls-tp-static-lsp-config-check-00
Abstract
This draft introduces a way to check the static lsp configuration (in
case of bi-directional LSP), so as to ease the trouble shooting of
static configurations in the MPLS network. The idea is to use Generic
Associated Channel (G-ACh) Advertisement Protocol (GAP) [I-D.ietf-
mpls-gach-adv] to transfer the LSP parameters to the far-end for
configuration checking.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License 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
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 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. GAP Extensions . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Static LSP Application Message . . . . . . . . . . . . . . 4
3.2. PE Procedure . . . . . . . . . . . . . . . . . . . . . . . 5
3.2.1. Sending LSP application Element TLV . . . . . . . . . . 7
3.2.2. Receiving LSP application Element TLV . . . . . . . . . 7
3.2.3. P Node / Transit Node message processing. . . . . . . . 8
3.2.4. LSP Configuration Check Process . . . . . . . . . . . . 10
3.2.5. Remote Label Advertisement . . . . . . . . . . . . . . 11
4 Security Considerations . . . . . . . . . . . . . . . . . . . . 11
5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 12
6 References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1 Normative References . . . . . . . . . . . . . . . . . . . 13
5.2 Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
1 Introduction
This draft introduces a way to check the static bidirectional lsp
configurations, so as to ease the trouble shooting of static
configurations in the MPLS network. The idea is to use Generic
Associated Channel (G-ACh) Advertisement Protocol (GAP)
[I-D.ietf-mpls-gach-adv] to transfer the LSP parameters to the next
hop node for checking the configuration. The methods described in
this draft will be very useful for checking the configuration of
static p2mp LSPs and MPLS TP LSPs.
Today once the transport path is configured statically there is no
way to check the consistency of the configurations across the
endpoints and transit nodes before making the status of the
underlying transport path to be operationally up.
1.1 Terminology
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].
2. Motivation
The manual configuration of static LSP requires configuring many
parameters in all the nodes in the LSP path, and these parameters
should be aligned, so as to make LSPs be operational. If one of the
parameters on the nodes which carries this LSP mis-matches, then
the LSP would not operate correctly. For the dynamic LSP, the
parameters would be negotiated by signaling session, and easy to find
out the configuration error if LSP is not operational UP. But for
static LSP, there is no such kind of signaling session, it is
difficult for operators to do trouble shooting, to figure out which
parameters on which node mis-matches.
Also in some occasions, the mis-configuration doesn't affect the data
traffic which can't be identified by the operators. As the data path
depends on the labels and label operations to be performed over the
packet, if the labels are configured properly and the LSP
configurations parameters like global ID / node ID is not matching
over the nodes, then the data traffic will be successful however the
OAM CV verification won't be successful.
In order to identify these mis-configurations and to ease the trouble
shooting of static LSP, this draft relies on GAP to transfer the
configuration parameters over the section, so as to check
configuration parameters automatically on each nodes to figure out
parameter mis-matching.
3. GAP Extensions
3.1. Static LSP Application Message
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Static PW | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime | Reserve |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Static LSP FEC Element TLV +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1
A new GAP application "Static LSP" is defined in this draft. The
Static LSP Application ID is to be assigned by IANA, and suggested
value is 0x0003.
Length: as per [I-D.ietf-mpls-gach-adv].
Lifetime: as per [I-D.ietf-mpls-gach-adv], and the default value is
suggested to be 120 seconds.
Static LSP FEC Element TLV for "Static LSP" GAP application:
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 | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Global ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Node ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Tunnel Num |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source LSP Num |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Global ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Node ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Tunnel Num |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination LSP Num |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TX Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RX Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Label Sub-TLV(0x0200) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Incoming Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Label Sub-TLV(0x0200) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outgoing Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2
The Static LSP FEC Element TLV type is to be assigned by IANA. The
Length field specifies the length in octets of the Static LSP FEC
Element and all Optional Interface Parameters Sub-TLVs.
The Static LSP FEC element TLV value MUST include the following:
o The Global ID, Node ID, Tunnel Num, LSP NUM fields MUST be set
as per [RFC6370].
o TX Sequence Number: The transmitted message sequence number for
the associated Static LSP FEC Element TLV.
o RX Sequence Number: The last received sequence number for the
associated Static LSP FEC Element TLV.
o Two Generic Label TLVs as defined in [RFC5036] to encode static
LSP incoming and outgoing labels in the order shown above.
The GAP Suppress message defined in [I-D.ietf-mpls-gach-adv]
applies to all TLVs for a given application. We define a new TLV,
static LSP suppress TLV, to suppress static LSP FEC element
transmission. Multiple static LSP FEC element TLVs could be included
in this TLV. The format would be as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|LSP Suppres TLV| Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Static LSP ID FEC +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ multiple static LSP ID FECs +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3
The type of static LSP suppress TLV is to be assigned by IANA.
The static LSP suppress TLV could be sent by a receiving PE to request
a transmitting PE to stop sending GAP messages for the static LSP FEC
Element TLVs in the static LSP suppress TLV.
The static LSP application MUST follow all procedures defined in
[I-D.ietf-mpls-gach-adv].
3.2. PE Procedure
The mechanism defined in this draft provides a verification tool for
the P2P LSP configuration information in all the nodes between the
tunnel endpoints. Upon provisioning or re-provisioning of a LSP
at any node, GAP messages carrying the static LSP application
TLV will be sent over the outgoing as well as the incoming interface
of this LSP (if any).
3.2.1. Sending LSP application Element TLV
When a LSP is configured on a PE node, and the corresponding
section / outgoing interface is UP, the PE node SHOULD send its
local LSP configuration information through GAP with local static
LSP element TLV.
The transmitting node MUST set the TX sequence number to a non-zero
value in Static LSP FEC Element TLV, and MUST increment the TX
sequence number each time any local LSP parameters change.
If the transmitting node has previously received a GAP message with
the static LSP FEC Element, the transmitting node MUST verify local
LSP parameters with the remote PE parameters as specified in section
3.2.4. The RX sequence number MUST be set to the previously received
TX sequence number, otherwise set to zero.
Whenever PE receives the GAP message with LSP suppress TLV, it SHOULD
stop sending GAP message with specified LSP information. Whenever
the PE updates locally LSP configuration information, PE could send
GAP message with static LSP element to update information.
3.2.2. Receiving LSP application Element TLV
The receiving node MUST update the remote LSP parameters associated with
a static LSP FEC Element TLV, when the received TX sequence number in
the GAP message is different from the last one received.
If the receiving PE has been provisioned locally with the LSP
parameters and has previously sent GAP message for the LSP parameters,
it MUST check if the RX sequence number in the received GAP message
is equal to the TX sequence number it previously sent.
If the RX sequence number is equal, the receiving node MUST send GAP
message with static LSP suppress TLV as a response to remote node, and
then verify local static LSP parameters with the remote static LSP FEC
parameters as specified in section 3.2.4.
Otherwise, if the RX sequence number is not equal, the receiving PE
MUST continue sending GAP message with static LSP FEC element TLV,
with the RX sequence number set to the last received TX sequence
number from the remote PE.
If there is no local LSP configuration associated with the static LSP
FEC Element TLV, the receiving PE MUST retain the remote static LSP
FEC Element information.
Whenever PE receives the GAP message with static LSP suppress TLV, it
MUST stop sending GAP messages with the specified static LSP FEC
element TLVs included in the static suppress TLV.
The GAP message of static LSP application SHOULD be sent at least
three times within lifetime.
3.2.3. P Node / Transit Node message processing
When a LSP is configured on transit node, and the corresponding
outgoing interface /section of forward and reverse component of LSP is UP,
then the transit node SHOULD send its local LSP configuration
information through GAP with "local static LSP element TLV". This GAP
message should be sent on both side of the LSP.
When the P node receives GAP message with static LSP element TLV from
head-end side of the LSP, it SHOULD save the LSP parameters in
"local static LSP element" TLV as head-end ingress LSP information
for a period of "lifetime" which is specified in the GAP message.
Similarly when the P node receives GAP message with static LSP
element TLV from tail-end side of the tunnel, it SHOULD save the LSP
parameters in "local static LSP element" TLV as tail-end ingress LSP
information for a period of "lifetime" which is specified in the GAP
message.
If the transmitting node has previously received a GAP message with
the static LSP FEC Element, the transmitting node MUST verify local
LSP parameters with the remote PE parameters as specified in section
4.2.3. The RX sequence number MUST be set to the previously received
TX sequence number, otherwise set to zero.
If the receiving GAP message also has "remote static LSP element"
TLV, P should check local head-end / tail-end LSP parameters with
that in "remote static LSP element" TLV. If both matches, P should
send GAP message with LSP suppress TLV contained the specified LSP
information to either the previous / next-hop router. If not, P send
GAP message with local LSP configuration information carried in
"local static LSP element" TLV, and the received remote LSP
configuration information carried in "remote static LSP element" TLV.
Once the P node has both the local and the remote static LSP element
it performs the LSP configuration verification process described in
the section 3.2.4. If the verification process fails then the
operational status of the tunnel should be down.
,
3.2.4. LSP Configuration Check Process
When the LSR / LER has both local and remote LSP parameters
for one LSP, it should do parameter checking as follows:
1. For MPLS TP LSPs, in PE node, verify the LSP identifiers
for the local static LSP element and remote static LSP elements
are same.
(i.e A1-{Node_ID::Tunnel_Num}::Z9-{Node_ID::Tunnel_Num}::LSP_Num
of source LSP parameter should match with
A1-{Node_ID::Tunnel_Num}::Z9-{Node_ID::Tunnel_Num}::LSP_Num
of destination LSP parameters)
2. For MPLS TP Tunnel, in transit node, verify the tunnel
identifiers of tail-end ingress LSP information and head-end
ingress LSP information matches with the local static LSP
element.
(i.e A1-{Node_ID::Tunnel_Num}::Z9-{Node_ID::Tunnel_Num}::LSP_Num
of source LSP parameter should match with
A1-{Node_ID::Tunnel_Num}::Z9-{Node_ID::Tunnel_Num}::LSP_Num
of destination LSP parameters)
3.2.5. Remote Label Advertisement
The mechanism described in this draft could also be used as label
advertisement, so as to avoid out_label negotiation manually between
two LSRs / LERs, and to avoid mis-configuration. As such, only outgoing
label will be included in the GAP message and this label will be used by
the nexthop remote PE as incoming label for the LSP.
4 Security Considerations
The mechanisms defined in this draft do not introduce any new threats
more than what's described in [I-D.ietf-mpls-gach-adv].
5 IANA Considerations
IANA is requested to allocate a new "Static LSP" Application ID in the
"G-Ach Advertisement Protocol Applications" registry.
Application ID Description Reference
-------------- ---------------------------- ------------
(TBD) Static LSP Application (this draft)
This document requests that IANA create a new registry, "GAP Static
LSP Application: TLV objects", with fields and initial value as
follows:
Type Name Type ID Reference
----------------------- ------- ------------
Static LSP FEC Element 0 (this draft)
Static LSP suppress TLV 1 (this draft)
The range of the Type ID field is 0 - 255.
The allocation policy for this registry is IETF Review.
6 References
6.1 Normative References
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC1776] Crocker, S., "The Address is the Message", RFC 1776, April
1 1995.
[I-D.ietf-mpls-gach-adv]
Frost, D., Bocci, M., and S. Bryant, "MPLS Generic
Associated Channel (G-ACh) Advertisement Protocol",
draft-ietf-mpls-gach-adv-00 (work in progress),
January 2012.
6.2 Informative References
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
Specification", RFC 5036, October 2007.
[RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport
Profile (MPLS-TP) Identifiers", RFC 6370, September 2011.
[RFC5513] Farrel, A., "IANA Considerations for Three Letter
Acronyms", RFC 5513, April 1 2009.
Authors' Addresses
Kingston Smiler Selvaraj
IPInfusion Software Ind Pvt LTD
Bangalore
India
Email: kingston.selvaraj@ipinfusion.com
Lizhong Jin
ZTE Corporation
889, Bibo Road
Shanghai, 201203, China
Email: lizhong.jin@zte.com.cn
