One document matched: draft-dai-mpls-tp-lock-instruct-00.txt
MPLS Working Group X. Dai
Internet-Draft B. Wu
Intended status: Standards Track J. Yang
Expires: April 19, 2010 ZTE Corporation
October 16, 2009
MPLS-TP Lock Instruction
draft-dai-mpls-tp-lock-instruct-00
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/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 April 19, 2010.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Dai, et al. Expires April 19, 2010 [Page 1]
Internet-Draft MPLS-TP Lock Instruction October 2009
Abstract
The aim of this document is to define an MPLS-TP OAM mechanism to
meet the requirements for Lock Instruction functionality as required
in MPLS-TP OAM Requirements document[MPLS-TP OAM Requirements]. The
protocol solutions developed to performe this function apply to P2P
bidirectional paths, P2P unidirectional paths and P2MP paths.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 4
2.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Definitions and terminology . . . . . . . . . . . . . . . 4
3. MPLS-TP Lock Instruction Message . . . . . . . . . . . . . . . 5
3.1. MPLS-TP Lock Instruction message Indentification . . . . . 5
3.1.1. In-band message Indentification . . . . . . . . . . . 5
3.1.2. Out-of-band message Indentification . . . . . . . . . 5
3.2. MPLS-TP Lock Instruction Message Format . . . . . . . . . 5
3.3. Optional TLVS . . . . . . . . . . . . . . . . . . . . . . 7
3.3.1. Source and Destination MEP TLV . . . . . . . . . . . . 8
3.3.2. Authentication TLV . . . . . . . . . . . . . . . . . . 8
4. MPLS-TP Lock Instruction Operations . . . . . . . . . . . . . 9
4.1. General Procedures . . . . . . . . . . . . . . . . . . . . 9
4.1.1. Sending a lock request message . . . . . . . . . . . . 9
4.1.2. Receiving a lock request message . . . . . . . . . . . 9
4.1.3. Sending a lock response message . . . . . . . . . . . 9
4.1.4. Receiving a lock response message . . . . . . . . . . 9
4.1.5. Unlock procedures . . . . . . . . . . . . . . . . . . 10
4.2. Example Topology . . . . . . . . . . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative references . . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Dai, et al. Expires April 19, 2010 [Page 2]
Internet-Draft MPLS-TP Lock Instruction October 2009
1. Introduction
MPLS-TP OAM Requirements document[MPLS-TP OAM Requirements] lists
architectural and functional requirements for the Operations,
Administration and Maintenance of MPLS Transport Profile. One of
these functionalities is Lock Instruction, which can enable an End
Point of a PW, LSP or Section to instruct its associated End Point(s)
to lock the PW, LSP or Section. Further, this function SHOULD be
performed on-demand between End Points of PWs, LSPs and Sections.
Besides, MPLS-TP OAM Requirements document also requires that the
protocol solution(s) developed to perform this function MUST also
apply to point-to-point associated bidirectional[RFC5654] LSPs,
point-to-point unidirectional LSPs and point-to-multipoint LSPs.
The solutions proposed in this draft can meet all the above
requirements.
When an operator wants to set a path into loopback mode for
management purposes, e.g., to test or verify connectivity to a
specific node on the path, to test the performance with respect to
delay/jitter/throughput, etc., especially out-of-service performance
measurement, which may affect user traffic transmition, one SHOULD
first set that path to lock mode. Through this mechnism, associated
nodes can distiguish this management situation from a failure
situation on the tested path.
Dai, et al. Expires April 19, 2010 [Page 3]
Internet-Draft MPLS-TP Lock Instruction October 2009
2. 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.1. Abbreviations
MPLS-TP: Transport Profile for Multi-protocal Label Switching
OAM: Operations, Administration and Maintenance
MEP: Maintenance End Point
MIP: Maintenance Intermediate Point
P2MP: Point to multi-point
P2P: point to point
TLV: Type-Length-Value
2.2. Definitions and terminology
unidirectional lock: A lock operation that only locks one direction
of a bidirectional path.
bidirectional lock: A lock operation that locks both directions of a
bidirectional path.
Dai, et al. Expires April 19, 2010 [Page 4]
Internet-Draft MPLS-TP Lock Instruction October 2009
3. MPLS-TP Lock Instruction Message
This section proposes one message format for lock instruction
operation, and two optional TLVs.
3.1. MPLS-TP Lock Instruction message Indentification
3.1.1. In-band message Indentification
In the in-band option, under MPLS label stack of the MPLS-TP LSP, the
ACH[RFC5586] with "MPLS-TP Lock Instruct" code point indicates that
the message is an MPLS-TP Lock Instruction message, the ACH format in
this case is shown as Figure 1:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version| Reserved |0xHH(MPLS-TP Lock Instruct) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: In-band message Indentification
The first nibble (0001) indicates the ACH. The version and the
reserved values are both set to 0. MPLS-TP lock instruction code
point is 0xHH. [HH to be assigned by IANA from the PW Associated
Channel Type registry.]
3.1.2. Out-of-band message Indentification
[To be added in future]
3.2. MPLS-TP Lock Instruction Message Format
The proposed format of an MPLS-TP Lock Instruction Message is shown
in Figure 2.
Dai, et al. Expires April 19, 2010 [Page 5]
Internet-Draft MPLS-TP Lock Instruction October 2009
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Message Type | Lock Type | Period |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Return Code | Cause Code | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV's |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: MPLS Lock Instruction Message Format
Version
The Version Number is currently 0. (Note: the version number is to
be incremented whenever a change is made that affects the ability of
an implementation to correctly parse or process an MPLS-TP Lock
Instruction message. These changes include any syntactic or semantic
changes made to any of the fixed fields, or to any Type-Length-Value
(TLV) or sub-TLV assignment or format that is defined at a certain
version number. The version number may not need to be changed if an
optional TLV or sub-TLV is added.)
Message Type
Two message types are defined as shown below:
Message Type Description
------------ --------------
0x0 lock request
0x1 lock response
0x2 unlock request
0x3 unlock response
Lock Type
Three lock types are defined as shown below:
Lock Type Description
--------- ------------------
0x0 unidirectional lock
0x1 bidirectional lock
Dai, et al. Expires April 19, 2010 [Page 6]
Internet-Draft MPLS-TP Lock Instruction October 2009
0x2 lock clear
Period
This feild (in seconds) is an indication of transmition interval for
MPLS-TP Lock instruction message.
Return Code
Value Meanings
------ ----------
0 Failure
1 Success
Cause Code
Value Meaning
----- -----------------------
0 No cause code
1 Fail to match destination MEP ID
2 Malformed lock request received
3 One or more of the TLVs is/are unknown
4 Authentication failed
5 MPLS-TP Path already locked
6 MPLS-TP Path already unlocked
7 Fail to lock MPLS-TP Path
8 Fail to unlock MPLS-TP Path
The Return code and Cause code only have meaning in a Lock response
message. In a Lock request message, the return code and cause code
must be set to zero and ignored on receipt.
3.3. Optional TLVS
This section defines two TLV types that will be used in an MPLS-TP
lock instruction message, both these two TLVs are optional.
Dai, et al. Expires April 19, 2010 [Page 7]
Internet-Draft MPLS-TP Lock Instruction October 2009
3.3.1. Source and Destination MEP TLV
This TLV is used to identify the source or destination node(s) of the
path that will be locked by an operator. In a Lock message, it MUST
only has one source MEP TLV; but for destination MEP TLV, it has one
in a P2P path while more than one in a P2MP path.
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 = TBD | Length = 0xx |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Variable Length Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Source and Destination MEP TLV
3.3.2. Authentication TLV
A variable length key can be carried in an optional authentication
TLV which can be included in the MPLS Lock request message. The use
of authentication key is outside the scope of this document.
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 = TBD | Length = 0xy |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Variable Length Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Authentication TLV
Dai, et al. Expires April 19, 2010 [Page 8]
Internet-Draft MPLS-TP Lock Instruction October 2009
4. MPLS-TP Lock Instruction Operations
4.1. General Procedures
4.1.1. Sending a lock request message
When an operator wants to lock an LSP, it first creates lock request
messages according to lock type: unidirectional lock or bidirectional
lock. Then it sends lock request messages periodically to
destination node(s) according to the interval specified by period
feild. This message may carries source/destination MEP TLV, or
authentication TLV.
4.1.2. Receiving a lock request message
When a node receives a lock request message, it first examines
whether the source or destination MEP match with itself. If source
MEP does not match, the event is logged and processing ceases. In
case of bidirectional lock, if the destination MEP does not match, it
will send a response message with a return code of 0 and a cause code
1. Futhermore, it will excute more examinations as specified in
section 4.2.
4.1.3. Sending a lock response message
Note: In case of unidirectional lock, the receipt node first
identifies whether the path is a bidirectional path or a
unidirectional path. If the requested path is unidirectional, it
will not send lock response messages to the source node; otherwise,
it will send a response message along the backward direction to the
source node.
After all the examinations in the former step, the receipt node of
lock request message will create a response message according to the
examined results, with proper return code and cause code.
4.1.4. Receiving a lock response message
When the source node receive a lock response, it will parse this
message, and:
(1) if the return code is "success", it will cease to send lock
request messages to destination node(s).
(2) if the return code is "failure", it will keep on sending lock
request messages to destination node(s) until it receives the first
lock response message with return code "success".
Dai, et al. Expires April 19, 2010 [Page 9]
Internet-Draft MPLS-TP Lock Instruction October 2009
4.1.5. Unlock procedures
When the source node wants to unlock a path which is in a locked
state, it SHOULD do as below:
(1) The source node sends an unlock request message to destination
node(s), thereinto lock type is "lock clear" and message type is
"unlock request".
(2) When a destination node receives such a unlock request message,
if it agrees to unlock this path as well as this path is a
bidirectional path, it will send an unlock response message to the
source node with a return code "success". If this path is a
unidirectional path, it won't send a respose message.
The source node will stop sending unlock request messages once it
receives a response message with a return code "success".
4.2. Example Topology
Assume an MPLS-TP bidirectional LSP (either associated bidirectional
or co-touted bidirectional[RFC5654]) A--B--C--D, where node A and D
are MEPs, B and C are MIPs[MPLS-TP Framework].
For unidirectional lock instruction, in case of lock the direction
from A to D:
(1) Node A periodcally sends Lock instruction messages to node D, in
which lock type is unidirectional lock, and message type is lock
request.
(2) On receipt of such a message, node B and C transparently transmit
it to next downstream node(s).
(3) While node D receives the message, it will analyse it and node D
knows that this is an unidirectional lock. it will create a lock
response massage according to the rules below:
a. if the source MEP ID does not match, the event is logged and
processing ceases.
b. if the destination MEP ID does not match, D sends a response with
a return code of 0 and a cause code 1.
Then D examines the message, and:
c. if the message is malformed, it sends a response with a return
code of 0 and a cause code 2 back to A.
Dai, et al. Expires April 19, 2010 [Page 10]
Internet-Draft MPLS-TP Lock Instruction October 2009
d. if message authentication fails, it MAY sends a response with a
return code of 0 and a cause code 4 back to A.
e. if any of the TLVs is not known, it sends a response with a return
code of 0 and a cause code 3 back to A. It may also includes the
unknown TLVs.
f. if the path is already locked, it sends a response with return
code of 1 (success) and a cause code 5 back to A.
g. if the path is not already locked and cannot be locked, it sends a
response with a return code of 0 and a cause code 7 back to A.
h. if the path is successfully locked, it sends a response with an
return code of 1 (success) and a cause code 0 back to A
After the above operations, the direction from A to D is locked,
while node D can also transmits user traffic and OAM massages to node
A.
For bidirectional lock instruct, which means lock both directions
from A to D and D to A:
(1) Node A periodcally sends Lock instruction messages to node D, in
which lock type is bidirectional lock, and message type is lock
request.
(2) On receipt of such a message, node B and C transparently transmit
it to next node(s).
(3) While node D receives this message, it will analyses it. After
that, node D knows that this is an bidirectional lock, it will create
a lock response massage according to the rules above, and sends it to
node A.
Through the above operations, both directions of this bidirectional
path are locked, which means node A and D can neither transmit user
traffic to each other.
Dai, et al. Expires April 19, 2010 [Page 11]
Internet-Draft MPLS-TP Lock Instruction October 2009
5. IANA Considerations
HH to be assigned by IANA from the PW Associated Channel Type
registry.
Dai, et al. Expires April 19, 2010 [Page 12]
Internet-Draft MPLS-TP Lock Instruction October 2009
6. Security Considerations
This section will be added in a future version.
Dai, et al. Expires April 19, 2010 [Page 13]
Internet-Draft MPLS-TP Lock Instruction October 2009
7. Acknowledgement
TBD.
Dai, et al. Expires April 19, 2010 [Page 14]
Internet-Draft MPLS-TP Lock Instruction October 2009
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.
[RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic
Associated Channel", RFC 5586, June 2009.
[RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N.,
and S. Ueno, "Requirements of an MPLS Transport Profile",
RFC 5654, September 2009.
8.2. Informative References
[MPLS-TP Framework]
Bocci, M., Bryant, S., Frost, D., and L. Levrau, "A
Framework for MPLS in Transport Networks", September 2009.
[MPLS-TP OAM Requirements]
Vigoureux, M., Ward, D., and M. Betts, "Requirements for
OAM in MPLS Transport Networks", August 2009.
Dai, et al. Expires April 19, 2010 [Page 15]
Internet-Draft MPLS-TP Lock Instruction October 2009
Authors' Addresses
Xuehui Dai
ZTE Corporation
4F,RD Building 2,Zijinghua Road
Yuhuatai District,Nanjing 210012
P.R.China
Phone: +86 025 52877612
Email: dai.xuehui@zte.com.cn
Bo Wu
ZTE Corporation
4F,RD Building 2,Zijinghua Road
Yuhuatai District,Nanjing 210012
P.R.China
Phone: +86 025 52877276
Email: wu.bo@zte.com.cn
Jian Yang
ZTE Corporation
5F,R&D Building 3,ZTE Industrial Park,XiLi LiuXian Road
Nanshan District,Shenzhen 518055
P.R.China
Phone: +86 755 26773731
Email: yang_jian@zte.com.cn
Dai, et al. Expires April 19, 2010 [Page 16]
| PAFTECH AB 2003-2026 | 2026-04-23 20:36:09 |