One document matched: draft-zhang-ccamp-rsvp-te-mpls-tp-tcm-config-00.txt
Network Working Group Fatai Zhang
Internet Draft Yi Lin
Category: Standards Track Huawei
Expires: January 2011 July 4, 2010
RSVP-TE extensions for TCM configuration in MPLS-TP network
draft-zhang-ccamp-rsvp-te-mpls-tp-tcm-config-00.txt
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 January 4, 2011.
Abstract
This specification describes the requirements of Tandem Connection
Monitoring (TCM) configuration via GMPLS control plane in MPLS-TP
network and provides the procedure of creating TCM path segment
tunnel on a transport path to meet the requirements of TCM
configuration.
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].
Zhang Expires January 2011 [Page 1]
draft-zhang-ccamp-rsvp-te-mpls-tp-tcm-config-00.txt July 2010
Table of Contents
1. Introduction..................................................2
2. Terminology...................................................3
3. Requirements of TCM Configuration.............................3
3.1. Introduction of TCM Path Segment Tunnel..................3
3.2. Requirements of TCM Configuration Using RSVP-TE..........4
4. Procedure of TCM Configuration................................5
4.1. Path Segment Tunnel Creation.............................6
4.2. LSP Rerouting in control plane...........................7
4.3. OAM Configuration........................................7
5. RSVP-TE Extension.............................................7
5.1. TCM_CONFIGURATION object in PATH message.................8
5.2. TCM_CONFIGURATION object in RESV message.................9
6. Security Considerations.......................................9
7. IANA Considerations...........................................9
8. Acknowledgments...............................................9
9. References....................................................9
10. Authors' Addresses..........................................10
1. Introduction
The MPLS Transport Profile (MPLS-TP) is being developed by ITU-T and
IETF. The MPLS-TP data plane framework and requirements are described
in [TP-FRWK] and [RFC5654], and the [TP-CP-FRWK] provides the
framework to support dynamic provisioning of MPLS-TP transport paths
via control plane.
The MPLS-TP Operations, Administration and Maintenance (OAM), which
is defined in [TP-OAM], is one of the most important and fundamental
functionalities in MPLS-TP. The OAM functionality is not only applied
on a transport path granularity, but also applied on arbitrary parts
of the transport path, defined as Tandem Connections. For the latter
case, a Tandem Connection Monitoring (TCM) is implemented by creating
a path segment tunnel that has a 1:1 association with the path
segment of the transport path that is to be uniquely monitored.
Therefore, the LSP is nested into the TCM path segment tunnel.
In case of TCM configuration using GMPLS control plane, the TCM path
segment tunnel needs to be created on an in-service LSP, which is not
supported in the current GMPLS RSVP-TE signaling.
Zhang Expires January 2011 [Page 2]
draft-zhang-ccamp-rsvp-te-mpls-tp-tcm-config-00.txt July 2010
This document provides the procedure of creating such outer layer
path segment tunnel on a transport path via control plane to meet the
requirement of automatic TCM configuration.
2. 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 [RFC2119].
3. Requirements of TCM Configuration
3.1. Introduction of TCM Path Segment Tunnel
This sub-section is informational which introduces the TCM and LSP
Path Segment Tunnel Monitoring in the MPLS-TP data plane.
As described in [TP-OAM], TCM is implemented by LSP Path Segment
Tunnel Monitoring which can be deployed to monitor the behavior of a
part of an LSP.
|<---------------------- LSP ---------------------->|
| |
| |<-- Path Segment Tunnel -->| |
| | | |
+-----------+===========================+-----------+
+-----------+===========================+-----------+
+-----+ +-----+ +-----+ +-----+ +-----+
| | | | | | | | | |
| A +------| B +------+ C +------+ D +------+ E |
| | | | | | | | | |
+-----+ +-----+ +-----+ +-----+ +-----+
-------> -------> -------> ------->
+--+----+ +--+--+----+ +--+--+----+ +--+----+
Data: |L1|Data| |L5|L3|Data| |L6|L3|Data| |L4|Data|
+--+----+ +--+--+----+ +--+--+----+ +--+----+
+--+--+----+ +--+--+----+
OAM packets: |L5|13|OAM | |L6|13|OAM |
+--+--+----+ +--+--+----+
Figure 1 - Example of Path Segment Monitoring
Figure 1 shows an example of TCM. Assume that there is an LSP passing
through node A, B, C, D and E. A path segment tunnel between node B
and D will be created when the operator wants to configure a TCM to
Zhang Expires January 2011 [Page 3]
draft-zhang-ccamp-rsvp-te-mpls-tp-tcm-config-00.txt July 2010
monitor this path segment. The path segment tunnel has a 1:1
association with the LSP which is nested into this tunnel. In other
words, the label stacking is performed between B and D, where the
inner layer label is corresponded with the LSP and the outer layer
label is corresponded with the tunnel.
Since the data packets of the LSP and the OAM packets for path
segment monitoring are using the same outer layer labels (i.e., the
tunnel labels), the LSP and the OAM session can be associated.
3.2. Requirements of TCM Configuration Using RSVP-TE
In most cases, the path segment tunnel for TCM is created when the
LSP is in service. When the network operator wants to monitor a
certain part of the LSP, a path segment tunnel needs to be set up by
RSVP-TE if the GMPLS control plane is in use.
Figure 2 and 3 show the label forwarding tables on each node that the
LSP pass through before and after the creation of the tunnel. In the
example shown in Figure 3, in order to create the TCM tunnel, the TCM
source node B needs to create a new label forwarding entry with two
labels, in which the in-label at the TCM destination node D of the
LSP (i.e., the label "L3") is treated as the inner layer out-label.
The current RSVP-TE can not support creation of such label forwarding
entry and creation of TCM tunnel on an existing LSP, so RSVP-TE needs
to be extended.
|<---------------------- LSP ---------------------->|
| |
+---------------------------------------------------+
+---------------------------------------------------+
+-----+ +-----+ +-----+ +-----+ +-----+
| | | | | | | | | |
| A +------| B +------+ C +------+ D +------+ E |
| | | | | | | | | |
+-----+ +-----+ +-----+ +-----+ +-----+
+-----------+ +-----------+ +-----------+ +-----------+ +-----------+
| Node A | | Node B | | Node C | | Node D | | Node E |
+-----+-----+ +-----+-----+ +-----+-----+ +-----+-----+ +-----+-----+
| in | out | | in | out | | in | out | | in | out | | in | out |
|label|label| |label|label| |label|label| |label|label| |label|label|
+-----+-----+ +-----+-----+ +-----+-----+ +-----+-----+ +-----+-----+
| -- | L1 | | L1 | L2 | | L2 | L3 | | L3 | L4 | | L4 | POP |
+-----+-----+ +-----+-----+ +-----+-----+ +-----+-----+ +-----+-----+
Figure 2 - Label Forwarding Tables before Creation of Tunnel
Zhang Expires January 2011 [Page 4]
draft-zhang-ccamp-rsvp-te-mpls-tp-tcm-config-00.txt July 2010
|<---------------------- LSP ---------------------->|
| |
| |<-- Path Segment Tunnel -->| |
| | | |
+-----------+===========================+-----------+
+-----------+===========================+-----------+
+-----+ +-----+ +-----+ +-----+ +-----+
| | | | | | | | | |
| A +------| B +------+ C +------+ D +------+ E |
| | | | | | | | | |
+-----+ +-----+ +-----+ +-----+ +-----+
+-----------+ +-----------+ +-----------+ +-----------+ +-----------+
| Node A | | Node B | | Node C | | Node D | | Node E |
+-----+-----+ +-----+-----+ +-----+-----+ +-----+-----+ +-----+-----+
| in | out | | in | out | | in | out | | in | out | | in | out |
|label|label| |label|label| |label|label| |label|label| |label|label|
+-----+-----+ +-----+-----+ +-----+-----+ +-----+-----+ +-----+-----+
| -- | L1 | | L1 |L3+L5| | L5 | L6 | | L6 | POP | | L4 | POP |
+-----+-----+ +-----+-----+ +-----+-----+ +-----+-----+ +-----+-----+
| L3 | L4 |
+-----+-----+
Figure 3 - Label Forwarding Tables after Creation of Tunnel
The basic requirements of setting up path segment tunnel on an LSP
for TCM by GMPLS RSVP-TE signaling include:
- No Disruption of User Traffic on the LSP.
- The path segment tunnel MUST pass through exactly the same
route as the LSP segment to be monitored.
- No extra bandwidth required. Since the tunnel and the LSP
segment have a 1:1 relationship, the bandwidth of the tunnel is
exactly the same as the LSP. Therefore, when setting up such
tunnel, no extra bandwidth is required to be reserved.
4. Procedure of TCM Configuration
When there is a need to monitor a part of an existing LSP between two
nodes (i.e., the TCM source node and the TCM destination node), the
Zhang Expires January 2011 [Page 5]
draft-zhang-ccamp-rsvp-te-mpls-tp-tcm-config-00.txt July 2010
network operator can instruct the TCM source node to perform the TCM
configuration. The GMPLS signaling is used to set up an RSVP-TE
session for the TCM tunnel between TCM source node and destination
node.
4.1. Path Segment Tunnel Creation
If the OAM MEP function can be supported, the TCM source node sends a
PATH message node by node along the LSP until the TCM destination
node. The ERO, which indicates the same route as the LSP segment to
be monitored, is necessary to be carried in this PATH message. The
tunnel sender address and the tunnel end point address in the PATH
message indicate the TCM source node and the TCM destination node.
Additionally, in order to perform bandwidth sharing between the TCM
tunnel and the LSP segment to be monitored, the PATH message for the
TCM tunnel should indicate using Share Explicit (SE) reservation
style and indicate which LSP to be monitored. Therefore, the
information of source and destination node IDs and the LSP ID of the
LSP to be monitored is needed to be carried in the PATH message.
A new TCM_CONFIGURATION object, as described in Session 5, is
introduced into the PATH message to carry this information.
If the OAM MEP function can be supported, the TCM destination node
responds a RESV message along the LSP until to the TCM source node.
Each node on the TCM tunnel performs a normal label distribution
procedure for the TCM tunnel and uses the SE style to share bandwidth
resources with the LSP.
Additionally, the TCM source node needs to use the in-label of the
LSP at the TCM destination node (i.e., L3 in figure 2 and 3) to
create the label forwarding entry for the TCM tunnel. But the TCM
source node may not have this label information because the Label
recording may not be performed in the LSP (i.e., the Label_Recording
flag in the SESSION_ATTRIBUTE object of the LSP is not set).
Therefore, the TCM destination node needs to include this in-label
in the RESV message. This label will be forwarded to the TCM source
node by the RESV messages sent by the intermediate nodes. This label
can be also carried in the TCM CONFIGUARION object. See Session 5 for
the detailed format of this object.
In Figure 3, for the TCM source node B, three labels are obtained:
- L3 from the downstream RESV message;
Zhang Expires January 2011 [Page 6]
draft-zhang-ccamp-rsvp-te-mpls-tp-tcm-config-00.txt July 2010
- The label of the TCM tunnel allocate by the downstream node (i.e.,
L5 in figure 2 and 3) from the downstream RESV message;
- The in-label of the LSP on the TCM source node (i.e., L1 in figure
2 and 3) from the forwarding entry related to the LSP on itself.
Then the TCM source node can creates a new label forwarding entry
which indicates that for the received data packet with a label of L1,
the label is replaced to two layer label, where the inner layer label
is L3 and the outer label is L5.
At last, the TCM source node enables this new created label
forwarding entry and disables the old one for the LSP, so that the
TCM tunnel is created and is ready for use.
4.2. LSP Rerouting in control plane
After setting up the TCM tunnel, the TCM tunnel is treated to be one
hop in the viewpoint of the original LSP. In other words, the route
of the LSP is changed so that a rerouting procedure is necessary to
be performed in the control plane. A Notify message is sent from the
TCM source node to the source node of the LSP to inform the change of
the route, so that the source node of the LSP can refresh the LSP
along the new route in the next refreshing periods.
4.3. OAM Configuration
After setting up the TCM tunnel, the OAM function can be initiated.
[OAM-CFG] describes the procedure of OAM configuration using GMPLS
control plane.
5. RSVP-TE Extension
A new TCM_CONFIGURATION object is introduced to carry the TCM related
information. The object class is TBD.
Zhang Expires January 2011 [Page 7]
draft-zhang-ccamp-rsvp-te-mpls-tp-tcm-config-00.txt July 2010
5.1. TCM_CONFIGURATION object in PATH message
When the TCM_CONFIGURATION object is carried in the PATH message, the
object carries the information of the monitored LSP.
C_Type = 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP source node IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP destination node IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
C-Type = 2:
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 source node IPv6 address |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP destination node IPv6 address |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The LSP source and destination node and the LSP ID are used to
indicate which LSP to be monitored.
Zhang Expires January 2011 [Page 8]
draft-zhang-ccamp-rsvp-te-mpls-tp-tcm-config-00.txt July 2010
5.2. TCM_CONFIGURATION object in RESV message
When the TCM_CONFIGURATION object is carried in the RESV message, the
object carries the in-label of the LSP at the TCM destination node.
C-Type = 3:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| in-label of LSP at TCM destination node |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6. Security Considerations
TBD.
7. IANA Considerations
TBD.
8. Acknowledgments
TBD.
9. References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[TP-FRWK] M. Bocci et al, "A Framework for MPLS in Transport
Networks", draft-ietf-mpls-tp-framework-06, October 16,
2009.
[RFC5654] B. Niven-Jenkins et al, "Requirements of an MPLS
Transport Profile", RFC 5654, September 2009.
[TP-OAM] I. Busi et al, "MPLS-TP OAM Framework", draft-ietf-mpls-
tp-oam-framework-06, April 21, 2010.
[RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching
(GMPLS) Architecture", RFC 3945, October 2004.
Zhang Expires January 2011 [Page 9]
draft-zhang-ccamp-rsvp-te-mpls-tp-tcm-config-00.txt July 2010
[TP-CP-FRWK] Loa Andersson et al, "MPLS-TP Control Plane Framework",
draft-ietf-ccamp-mpls-tp-cp-framework-02, June 18, 2010.
[OAM-CFG] A. Takacs et al, "OAM Configuration Framework and
Requirements for GMPLS RSVP-TE", draft-ietf-ccamp-oam-
configuration-fwk-03, January 28, 2010.
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description", RFC
3471, January 2003.
[RFC3473] L. Berger, Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC
3473, January 2003.
10. Authors' Addresses
Fatai Zhang
Huawei Technologies
F3-5-B R&D Center, Huawei Base
Bantian, Longgang District
Shenzhen 518129 P.R.China
Phone: +86-755-28972912
Email: zhangfatai@huawei.com
Yi Lin
Huawei Technologies Co., Ltd.
F3-5-B R&D Center, Huawei Base,
Bantian, Longgang District
Shenzhen 518129 P.R.China
Phone: +86-755-28972914
Email: linyi_hw@huawei.com
Intellectual Property
Zhang Expires January 2011 [Page 10]
draft-zhang-ccamp-rsvp-te-mpls-tp-tcm-config-00.txt July 2010
The IETF Trust 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 any IETF 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 to identify any
such rights.
Copies of Intellectual Property 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
any standard or specification contained in an IETF Document. Please
address the information to the IETF at ietf-ipr@ietf.org.
The definitive version of an IETF Document is that published by, or
under the auspices of, the IETF. Versions of IETF Documents that are
published by third parties, including those that are translated into
other languages, should not be considered to be definitive versions
of IETF Documents. The definitive version of these Legal Provisions
is that published by, or under the auspices of, the IETF. Versions of
these Legal Provisions that are published by third parties, including
those that are translated into other languages, should not be
considered to be definitive versions of these Legal Provisions.
For the avoidance of doubt, each Contributor to the IETF Standards
Process licenses each Contribution that he or she makes as part of
the IETF Standards Process to the IETF Trust pursuant to the
provisions of RFC 5378. No language to the contrary, or terms,
conditions or rights that differ from or are inconsistent with the
rights and licenses granted under RFC 5378, shall have any effect and
shall be null and void, whether published or posted by such
Contributor, or included with or in such Contribution.
Disclaimer of Validity
All IETF Documents and the information contained therein 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
Zhang Expires January 2011 [Page 11]
draft-zhang-ccamp-rsvp-te-mpls-tp-tcm-config-00.txt July 2010
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 THEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Copyright Notice
Copyright (c) 2010 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.
Zhang Expires January 2011 [Page 12]
| PAFTECH AB 2003-2026 | 2026-04-24 12:22:20 |