Network Working Group X. Fu
Internet-Draft Q. Wang
Intended status: Standards Track Y. Bao
Expires: April 28, 2011 ZTE Corporation
R. Jing
X. Huo
China Telecom
October 25, 2010
RSVP-TE Signaling Extension for Explicit Control of LSP Boundary in A
GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN)
draft-fuxh-ccamp-boundary-explicit-control-ext-01
Abstract
[RFC5212] defines a Multi-Region and Multi-Layer Networks (MRN/MLN).
[RFC4206] introduces a region boundary determination algorithm and a
Hierarchy LSP (H-LSP) creation method. However, in some scenarios,
some attributes have to be attached with the boundary nodes in order
to explicit control the hierarchy LSP creation. This document
extends GMPLS signaling protocol for the requirement of explicit
control the hierarchy LSP creation.
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 April 28, 2011.
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
Fu, et al. Expires April 28, 2011 [Page 1]
Internet-Draft RSVP-TE for LSP Boundary Control October 2010
(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. Requirement of Explicit Control of Hierarchy LSP Creation . . 3
2.1. Selection of Server Layer/Sub-Layer . . . . . . . . . . . 3
2.2. Selection/Creation of FA-LSP based on characteristics
of server layer . . . . . . . . . . . . . . . . . . . . . 4
2.3. Configuration of Multi Stages Multipelxing Hierarchy . . . 5
3. Explicit Route Boundary Object (ERBO) . . . . . . . . . . . . 6
3.1. Server Layer/Sub-Layer Attributes TLV . . . . . . . . . . 8
3.2. Multiplexing Hierarchy Attribute TLV . . . . . . . . . . . 9
3.3. Latency Attribute TLV . . . . . . . . . . . . . . . . . . 10
4. Signaling Procedure . . . . . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Fu, et al. Expires April 28, 2011 [Page 2]
Internet-Draft RSVP-TE for LSP Boundary Control October 2010
1. Introduction
[RFC5212] defines a Multi-Region and Multi-Layer Networks (MRN/MLN).
[RFC4206] introduces a region boundary determination algorithm and a
Hierarchy LSP (H-LSP) creation method. However, in some scenarios,
some attributes have to be attached with the boundary nodes in order
to explicitly control the hierarchy LSP creation. This document
extends GMPLS signaling protocol for the requirement of explicit
control the hierarchy LSP creation.
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. Requirement of Explicit Control of Hierarchy LSP Creation
2.1. Selection of Server Layer/Sub-Layer
[RFC4206] describes a region boundary determination algorithm and a
hierarchical LSP creation method. This region boundary determination
algorithm and LSP creation method are well applied to Multi-Region
Network. However it isn't fully applied to Multi-Layer Network. In
the following figure, three LSPs belong to the same TDM region and
different latyers, but the sub-layer boundary node could not
determine which lower layer should be triggered according to the
region boundary determination algorithm defined in [RFC4206]. Thus
the higher layer (VC4 in figure 1) signaling can't trigger the lower
layer (STM-N in figure 1) LSP creation. It needs to explicitly
describe which sub-layer should be triggered in the signaling
message.
A B C D E F
+---+ STM-N +---+ STM-N +----+ OTUk +----+ STM-N +---+ STM-N +---+
|VC4|-------|VC4|-------|ODUk|------|ODUk|-------|VC4|-------|VC4|
+---+ +---+ +----+ +----+ +---+ +---+
|<-------------------------- VC4 LSP ------------------------->|
|<------------- STM-N LSP ------------>|
|<--ODUk LSP-->|
Figure 1: Example of Server Layer/Sub-Layer Selection
Fu, et al. Expires April 28, 2011 [Page 3]
Internet-Draft RSVP-TE for LSP Boundary Control October 2010
2.2. Selection/Creation of FA-LSP based on characteristics of server
layer
ITU-T G.800 defines Composite Link. Individual component links in a
composite link may be supported by different transport technologies
such as OTN, MPLS-TP or SDH/SONET. Even if the transport technology
implementing the component links is identical, the characteristics
(e.g., latency) of the component links may differ. Operator may
prefer its traffic to be transported over a specific transport
technology server layer. Further more, operator may prefer its
traffic to be transported over a specific transport technology
component link with some specific characteristics (e.g.,latency). So
it desires to explicitly control the component link selection based
on the attributes (e.g., switching capability and latency) attached
with the boundary nodes during the signaling.
Latency is a key requirement for service provider. Restoration
and/or protection can impact "provisioned" latency. The key driver
for this is stock/commodity trading applications that use data base
mirroring. A few delicacy can impact a transaction. Therefore
latency and latency SLA is one of the key parameters that these "high
value" customers use to select a private pipe line provider. So it
desires to explicitly convey latency SLA to the boundary nodes where
the hierarchy LSP will be triggered.
___ ___
MPLS-based LSP | | | |
o-----o-----o-----|-o | | o-|-----o-----o-----o
| | | |
| |OTN FA-LSP with latency 1| |
| o-|-------------------------|-o |
| | | |
| |OTN FA-LSP with latency 2| |
| o-|-------------------------|-o |
| . | . | . |
| . | . | . |
| . | . | . |
| |OTN FA-LSP with latency n| |
| o-|-------------------------|-o |
|___| |___|
Figure 2: Example of FA-LSP Selection/Creation based on Latency
In Figure 2, a LSP traffic is over a composite link whose component
links with different latency characteristic are supported by OTN. In
order to meet the latency SLA, it needs to explicitly limit the
Fu, et al. Expires April 28, 2011 [Page 4]
Internet-Draft RSVP-TE for LSP Boundary Control October 2010
latency between boundary nodes to create an OTN tunnel.
2.3. Configuration of Multi Stages Multipelxing Hierarchy
In Figure 3, node B and C in the OTN network are connected to 2.5G TS
network by two OTU3 link. They can support flexible multi stages
multiplexing hierarchies. There are two multi stages multiplexing
hierarchies for ODU0 being mapped into OTU3 link in B and C of Figure
1 (i.e., ODU0-ODU1-ODU3 and ODU0-ODU2-ODU3). So path computation
entity has to determine which kind of multi stages multiplexing
hierarchies should be used for the end-to-end ODU0 service and the
type of tunnel (FA-LSP). In Figure 3, if path computation entity
select the ODU0-ODU2-ODU3 multi stages multiplexing hierarch in Node
B and C for one end-to-end ODU0 service from A to Z, there has to be
an ODU2 tunnel between B and C. The selection of multi stages
multiplexing hierarchies is based on the operator policy and the
equipment capability. How to select the multiplexing hierarchies is
the internal behavior of path computation entity.
ODU1-ODU3
ODU2-ODU3
ODU0-ODU2 ODU0-ODU1-ODU3
ODU1-ODU2 ODU0-ODU2-ODU3
ODUflex-ODU2 ODUflex-ODU2-ODU3
| _______ |
___ _|_____ / \ _|_____ ___
| A | | | B | | 40G | | | C | | Z |
| o-|-----------|-o o-|----| Network |----|-o o-|-----------|-o |
|___| OTU2 Link |_____|_| |(2.5G TS)| |_____|_| OTU2 Link |___|
(1.25G TS) | \_______/ | (1.25G TS)
| |
ODU0-ODU1-ODU3 ODU0-ODU2
ODU0-ODU2-ODU3 ODU1-ODU2
ODUflex-ODU2-ODU3 ODUflex-ODU2
ODU1-ODU2-ODU3
ODU1-ODU3
ODU2-ODU3
Figure 3 Example of Multi-Stages Multiplexing Hierarchy Selection
If path computation entity select the ODU0-ODU2-ODU3 for ODU0 being
mapped into OTU3 Link, the multi stages multiplexing hierarchy has to
be carried in signaling message to node B and C. After B receives the
signaling message, it will triggered a creation of and ODU2 FA-LSP
base on [RFC4206] and the selection of multi stages multiplexing
hierarchy. Node B and C must config this kind of multi stages
multiplexing hierarchy (i.e., ODU0-ODU2-ODU3) to its data plane. So
Fu, et al. Expires April 28, 2011 [Page 5]
Internet-Draft RSVP-TE for LSP Boundary Control October 2010
data plane can multplex and demultiplex the ODU0 signal from/to ODU3
for a special end-to-end ODU0 service in terms of the control plane's
configuration.
In Figure 4, the switching capability (e.g., TDM), switching
granuality (i.e., ODU3) and multi stages multiplexing hierarchy
(ODU0-ODU1-ODU3-ODU4) must be specified during signaling. Because
the switching capability (TDM) and switching granuality (ODU3)
information is not enough for data plane to know ODU0 is mapped into
ODU3 tunnel by ODU0-ODU1-ODU3 then ODU4. In order to explicit
specify multi stages multiplexing hierarchy, the switching
capability, switching granuality and multi stages multiplexing
hierarchy (ODU0-ODU1-ODU3) must be carried in the signaling message.
2|0 0|2 2|0 0|1|3|4 4|3 3|4 4|3|1|0 0|2 2|0 0|2
_______ _______ _______ _______ _______
| A | | B | | C | | E | | F |
-|-o o-|------|-o o-|------|-o o-|------|-o o-|------|-o o-|-
|_______| |_______| |_______| |_______| |_______|
ODU3 Tunnel
ODU0 Service -----------------------
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-----------------------
Figure 4 Example of Multi-Stages Multiplexing Hierarchy Selection
3. Explicit Route Boundary Object (ERBO)
In order to explicitly control hierarchy LSP creation, this document
introduce a new object (ERBO- Explicit Route Boundary Object) carried
in RSVP-TE message. The format of ERBO object is the same as ERO.
The ERBO including the region boundaries information and some
specific attributes (e.g., latency) can be carried in Path message.
One pairs or multiple pairs of nodes within the ERBO can belong to
the same layer or different layers.
This document introduce a new sub-object (BOUNDARY_ATTRIBUTES) carry
the attributes of the associated hop specified in the ERBO. It
allows the specification and reporting of attributes relevant to a
particular hop of the signaled LSP. It follows an IPv4 or IPv6
prefix or unnumbered Interface ID sub-object in ERBO. A list of
attribute TLV can be inserted into ERBO.
Fu, et al. Expires April 28, 2011 [Page 6]
Internet-Draft RSVP-TE for LSP Boundary Control October 2010
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| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Attribute TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5 Format of BOUNDARY_ATTRIBUTES
- This field indicates different attribute TLV sub-objects.
- The total length of the sub-object in bytes, including the Type
and Length fields. The value of this field is always a multiple
of 4.
- Attribute TLVs: This field carries different TLV according to the
Type filed.
A list of attributes TLV can be inserted into ERBO. These attributes
may represent the following information. It can be further extended
to carry other specific requirement in the future.
- Server Layer (e.g., PSC, L2SC, TDM, LSC, FSC) or Sub-Layer (e.g.,
VC4, VC11, VC4-4c, VC4-16c, VC4-64c, ODU0, ODU1, ODU2, ODU3, ODU4)
used for boundary node to trigger one specific corresponding
server layer or Sub-Layer FA-LSP creation. The region boundary
node may support multiple interface switching capabilities and
multiple switching granularities. It is very useful to indicate
which server layer and/or sub-layer to be used at the region
boundary node.
- Multiplexing hierarchy (e.g., ODU0-ODU1-ODU3-ODU4) used for
boundary node to configure it to the data plane and trigger one
specific corresponding tunnel creation.
- Server Layer and/or Sub-Layer's LSP Latency SLA (e.g., minimum
latency value, maximum latency value, average latency value and
latency variation value). Boundary node select a FA or create a
FA-LSP based on the latency limitation.
The format of the Attributes TLV is as follows:
Fu, et al. Expires April 28, 2011 [Page 7]
Internet-Draft RSVP-TE for LSP Boundary Control October 2010
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(IANA) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Attribute Specific Information //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following types are supported.
Type | Information
------+-------------------------------
TBD | server layer/sub-layer
TBD | server layer/sub-layer characteristics (e.g., latency)
TBD | multi stage multiplexing hierarchy
3.1. Server Layer/Sub-Layer Attributes TLV
Switching capabilities and switching granularities of the region
boundary can be carried in Attribute TLV. With these information
carried in the RSVP-TE path message, the region boundary node can
directly trigger one corresponding server layer or sub-layer FA-LSP
creation which is defined in the Attribute TLV. The format of the
Attribute TLV is shown 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type(IANA) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Server Layer | Sub-Layer | Reserve |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: indicates different values of Attribute TLV.
o Length: indicates the total length of this Attribute TLV value.
o Server Layer: Indicates which corresponding server layer should be
triggered by the boundary node. The value of server layer is the
same as the switching capability [RFC3471].
o Sub-Layer: If there are several sub-layers within one server
layer, it can further indicates which sub-layer should be
triggered by the boundary node.
Fu, et al. Expires April 28, 2011 [Page 8]
Internet-Draft RSVP-TE for LSP Boundary Control October 2010
* SDH/SONET: VC4, VC11, VC12, VC4-4c, VC4-16c, VC4-64c.
* OTN: ODU0, ODU1, ODU2, ODU3, ODU2e, ODU4, and so on
3.2. Multiplexing Hierarchy Attribute TLV
Multiplexing Hierarchy Attribute TLV indicates the multiplexing
hierarchies (e.g., ODU0-ODU2-ODU3) used for boundary node to
configure it to the data plane and trigger one specific corresponding
tunnel creation. The type of this sub-TLV will be assigned by IANA,
and length is eight octets. The value field of this sub-TLV contains
multi stages multiplexing hierachies constraint information of the
link port.
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 (IANA) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| F | Number | Reserve |MSMH 1 | ...MSMC 1... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MSMH 2 | ...MSMC 2... | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MSMH M | ...MSMC M... | padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o F (2 bits): Indicates the multi stages multiplexing hierarchies
are included or excluded.
* 0 - Inclusive Multiplexing Hierarchies:Indicates that the
object/TLV contains one or more multi stages multiplexing
hierarchies which can be supported.
* 1 - Exclusive Multiplexing Hierarchies:Indicates that the
object/TLV contains one or more multi stages multiplexing
hierarchies which can't be supported.
o Number (8 bits): Indicates the total nunmber of multi stages
multiplexing hierarchies which are supported or prohibited by the
link port.
o Reserve (8 bits): for future use.
o (MSMH 1, MSMC 1), (MSMH 2, MSMC 2), ... ,(MSMH M, MSMC M):
Indicates each multi stages multiplexing capability detailed
information.
Fu, et al. Expires April 28, 2011 [Page 9]
Internet-Draft RSVP-TE for LSP Boundary Control October 2010
* MSMH 1, MSMH2, ... , MSMH M (4 bits): Indicates the numbers of
Multi Stages Multiplexing Hierarchies (MSMH).
+ MSMH = 1: It indicates ODUi is mapped into ODUk (k > i) by
single stage multiplexing (e.g., ODU0-ODU3).
+ MSMH > 1: It indicates ODUi is mapped into ODUk (k > i) by
multi stages multiplexing (e.g., ODU0-ODU1-ODU3).
* MSMC 1, MSMC 2, ... ,MSMC M: Indicates the detailed information
of multi stages multiplexing capability. The length of Multi
Stages Multiplexing Capability (MSMC) information depends on
the multi stages multiplexing hierarchies (MSMH). The length
of MSMC is (MSMH+1) * 4. Each ODUk (k=1, 2, 3, 4, 2e, flex) is
indicated by 4 bits. Following is the Signal Type for G.709
Amendment 3.
Value Type
----- ----
0000 ODU0
0001 ODU1
0010 ODU2
0011 ODU3
0100 ODU4
0101 ODU2e
0110 ODUflex
7-15 Reserved (for future use)
o The padding is used to make the Multi Stages Multiplexing
Capability Descriptor sub-TLV 32-bits aligned.
3.3. Latency Attribute TLV
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(IANA) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum Latency Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Latency Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Average Latency Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Latency Variation Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fu, et al. Expires April 28, 2011 [Page 10]
Internet-Draft RSVP-TE for LSP Boundary Control October 2010
- Minimum Latency Value: a minimum value indicates the latency
performance parameters which server layer/sub-layer LSP must meet.
- Maximum Latency Value: a maximum value indicates the latency
performance parameters which server layer/sub-layer LSP must meet.
- Average Latency Value: a average value indicates the latency
performance parameters which server layer/sub-layer LSP must meet.
- Latency Variation Value: a variation value indicates the latency
performance parameters which server layer/sub-layer LSP must meet.
4. Signaling Procedure
In order to signal an end-to-end LSP across multi layer, the LSP
source node sends the RSVP-TE PATH message with ERO which indicates
LSP route and ERBO which indicates the LSP route boundary. When a
interim node receives a PATH message, it will check ERBO to see if it
is the layer boundary node. If a interim node isn't a layer
boundary, it will process the PATH message as the normal one of
single layer LSP. If a interim node finds its address is in ERBO, it
is a layer boundary node. So it will directly extract another
boundary egress node and other detail Attribute TLV infomration
(e.g., Latency) from ERBO. If it is necessary, it will also extract
the server layer/sub-layer routing information from ERO based on a
pair of boundary node. Then the layer boundary node holds the PATH
message and selects or creates a server layer/sub-layer LSP based on
the detailed information of Attribute TLV (e.g., Latency) carried in
ERBO.
On reception of a Path message containing BOUNDARY_ATTRIBUTES whose
type of Attributes TLV is Multi States Multiplexing Hierarchy Sub-
TLV, The interim node checks the local data plane capability to see
if this kind of multi stages multiplexing/demultiplexing hierarchy is
acceptable on specific interface. As there is an acceptable kind of
multi stages multiplexing/demultiplexing, it must determin an ODUk
tunnel must be created between a pair of boundary node. The kind of
multi stages multiplexing/demultiplexing hierarchy must be configed
into the data plane.
5. Security Considerations
TBD
Fu, et al. Expires April 28, 2011 [Page 11]
Internet-Draft RSVP-TE for LSP Boundary Control October 2010
6. IANA Considerations
TBD
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Functional Description", RFC 3471,
January 2003.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support
of Generalized Multi-Protocol Label Switching (GMPLS)",
RFC 4203, October 2005.
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP)
Hierarchy with Generalized Multi-Protocol Label Switching
(GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux,
M., and D. Brungard, "Requirements for GMPLS-Based Multi-
Region and Multi-Layer Networks (MRN/MLN)", RFC 5212,
July 2008.
[RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element
(PCE) Communication Protocol (PCEP)", RFC 5440,
March 2009.
7.2. Informative References
[I-D.ietf-ccamp-gmpls-mln-extensions]
Papadimitriou, D., Vigoureux, M., Shiomoto, K., Brungard,
Fu, et al. Expires April 28, 2011 [Page 12]
Internet-Draft RSVP-TE for LSP Boundary Control October 2010
D., and J. Roux, "Generalized Multi-Protocol Label
Switching (GMPLS) Protocol Extensions for Multi-Layer and
Multi-Region Networks (MLN/MRN)",
draft-ietf-ccamp-gmpls-mln-extensions-12 (work in
progress), February 2010.
[I-D.ietf-rtgwg-cl-requirement]
Ning, S., Malis, A., McDysan, D., Yong, L., JOUNAY, F.,
and Y. Kamite, "Requirements for MPLS Over a Composite
Link", draft-ietf-rtgwg-cl-requirement-00 (work in
progress), February 2010.
Authors' Addresses
Xihua Fu
ZTE Corporation
West District,ZTE Plaza,No.10,Tangyan South Road,Gaoxin District
Xi An 710065
P.R.China
Phone: +8613798412242
Email: fu.xihua@zte.com.cn
URI: http://wwwen.zte.com.cn/
Qilei Wang
ZTE Corporation
No.68 ZiJingHua Road,Yuhuatai District
Nanjing 210012
P.R.China
Phone: +8613585171890
Email: wang.qilei@zte.com.cn
URI: http://www.zte.com.cn/
Yuanlin Bao
ZTE Corporation
5/F, R.D. Building 3, ZTE Industrial Park, Liuxian Road
Shenzhen 518055
P.R.China
Phone: +86 755 26773731
Email: bao.yuanlin@zte.com.cn
URI: http://www.zte.com.cn/
Fu, et al. Expires April 28, 2011 [Page 13]
Internet-Draft RSVP-TE for LSP Boundary Control October 2010
Ruiquan Jing
China Telecom
Email: jingrq@ctbri.com.cn
Xiaoli Huo
China Telecom
Email: huoxl@ctbri.com.cn
Fu, et al. Expires April 28, 2011 [Page 14]