One document matched: draft-fuxh-ccamp-boundary-explicit-control-ext-01.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3209 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3209.xml">
<!ENTITY RFC3471 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3471.xml">
<!ENTITY RFC3473 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3473.xml">
<!ENTITY RFC4203 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4203.xml">
<!ENTITY RFC4206 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4206.xml">
<!ENTITY RFC4655 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4655.xml">
<!ENTITY RFC5212 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5212.xml">
<!ENTITY RFC5440 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5440.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="std" docName="draft-fuxh-ccamp-boundary-explicit-control-ext-01" ipr="trust200902">
<front>
<title abbrev="RSVP-TE for LSP Boundary Control">
RSVP-TE Signaling Extension for Explicit Control of LSP Boundary in A GMPLS-Based
Multi-Region and Multi-Layer Networks (MRN/MLN)
</title>
<author fullname="Xihua Fu" initials="X" surname="Fu">
<organization>ZTE Corporation</organization>
<address>
<postal>
<street>West District,ZTE Plaza,No.10,Tangyan South Road,Gaoxin District</street>
<city>Xi An</city>
<code>710065</code>
<country>P.R.China</country>
</postal>
<phone>+8613798412242</phone>
<email>fu.xihua@zte.com.cn</email>
<uri>http://wwwen.zte.com.cn/</uri>
</address>
</author>
<author fullname="Qilei Wang" initials="Q.L" surname="Wang">
<organization>ZTE Corporation</organization>
<address>
<postal>
<street>No.68 ZiJingHua Road,Yuhuatai District</street>
<city>Nanjing</city>
<code>210012</code>
<country>P.R.China</country>
</postal>
<phone>+8613585171890</phone>
<email>wang.qilei@zte.com.cn</email>
<uri>http://www.zte.com.cn/</uri>
</address>
</author>
<author fullname="Yuanlin Bao" initials="Y.L" surname="Bao">
<organization>ZTE Corporation</organization>
<address>
<postal>
<street>5/F, R.D. Building 3, ZTE Industrial Park, Liuxian Road </street>
<city>Shenzhen</city>
<code>518055</code>
<country>P.R.China</country>
</postal>
<phone>+86 755 26773731</phone>
<email>bao.yuanlin@zte.com.cn</email>
<uri>http://www.zte.com.cn/</uri>
</address>
</author>
<author fullname="Ruiquan Jing" initials="R" surname="Jing">
<organization>China Telecom</organization>
<address>
<email>jingrq@ctbri.com.cn</email>
</address>
</author>
<author fullname="Xiaoli Huo" initials="X" surname="Huo">
<organization>China Telecom</organization>
<address>
<email>huoxl@ctbri.com.cn</email>
</address>
</author>
<date year="2010"/>
<area>Routing</area>
<workgroup>Network Working Group</workgroup>
<keyword>Explicit Control</keyword>
<keyword>Route Boundary</keyword>
<keyword>Multi-Layer</keyword>
<keyword>PCE</keyword>
<abstract>
<t>
[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.
</t>
</abstract>
</front>
<middle>
<!-- 1st -->
<section title="Introduction">
<t>
[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.
</t>
<section title="Conventions Used In This Document">
<t>
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].
</t>
</section>
</section>
<!-- 2nd -->
<section title="Requirement of Explicit Control of Hierarchy LSP Creation">
<section title="Selection of Server Layer/Sub-Layer">
<t>[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.
<figure anchor="Figure 1" title="Example of Server Layer/Sub-Layer Selection">
<artwork align="left">
<![CDATA[
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-->|]]>
</artwork>
</figure>
</t>
</section>
<section title="Selection/Creation of FA-LSP based on characteristics of server layer">
<t>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.
</t>
<t>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.
</t>
<figure anchor="Figure 2" title="Example of FA-LSP Selection/Creation based on Latency">
<artwork align="left">
<![CDATA[
___ ___
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 |
|___| |___|
]]>
</artwork>
</figure>
<t>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 latency between boundary nodes to create an OTN tunnel.
</t>
</section>
<section title="Configuration of Multi Stages Multipelxing Hierarchy">
<t>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.
<figure title="Figure 3 Example of Multi-Stages Multiplexing Hierarchy Selection">
<artwork align="left">
<![CDATA[
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]]>
</artwork>
</figure>
</t>
<t>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 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.
</t>
<t>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.
<figure title="Figure 4 Example of Multi-Stages Multiplexing Hierarchy Selection">
<artwork align="left">
<![CDATA[
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 -----------------------
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-----------------------
]]>
</artwork>
</figure>
</t>
</section>
</section>
<!--3rd-->
<section title="Explicit Route Boundary Object (ERBO)">
<t>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.
<vspace blankLines="1"/>
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.
<figure title="Figure 5 Format of BOUNDARY_ATTRIBUTES">
<artwork align="center">
<![CDATA[
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 ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]>
</artwork>
</figure>
</t>
<t>
<list style="hanging">
<t hangText="-">
This field indicates different attribute TLV sub-objects.
</t>
<t hangText="-">
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.
</t>
<t hangText="-">
Attribute TLVs: This field carries different TLV according to the Type filed.
</t>
</list>
</t>
<t>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.
<list style="hanging">
<t hangText="-">
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.
</t>
<t hangText="-">
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.
</t>
<t hangText="-">
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.
</t>
</list>
</t>
<t>The format of the Attributes TLV is as follows:
<figure>
<artwork align="center">
<![CDATA[
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 //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]>
</artwork>
</figure>
</t>
<t>The following types are supported.
<figure>
<artwork align="center"><![CDATA[
Type | Information
------+-------------------------------
TBD | server layer/sub-layer
TBD | server layer/sub-layer characteristics (e.g., latency)
TBD | multi stage multiplexing hierarchy]]>
</artwork>
</figure>
</t>
<section title="Server Layer/Sub-Layer Attributes TLV">
<t>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.
</t>
<figure>
<artwork align="center"><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]>
</artwork>
</figure>
<t>
<list style="symbols">
<t>Type: indicates different values of Attribute TLV.</t>
<t>Length: indicates the total length of this Attribute TLV value.</t>
<t>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].</t>
<t>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.
<list style="symbols">
<t>SDH/SONET: VC4, VC11, VC12, VC4-4c, VC4-16c, VC4-64c.</t>
<t>OTN: ODU0, ODU1, ODU2, ODU3, ODU2e, ODU4, and so on</t>
</list>
</t>
</list>
</t>
</section>
<section title="Multiplexing Hierarchy Attribute TLV">
<t>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.
</t>
<figure>
<artwork align="left">
<![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]>
</artwork>
</figure>
<t>
<list style="symbols">
<t>F (2 bits): Indicates the multi stages multiplexing hierarchies are included or excluded.
<list style="symbols">
<t>0 - Inclusive Multiplexing Hierarchies:Indicates that the object/TLV contains one or more multi stages multiplexing hierarchies
which can be supported.
</t>
<t>1 - Exclusive Multiplexing Hierarchies:Indicates that the object/TLV contains one or more multi stages multiplexing hierarchies
which can't be supported.
</t>
</list>
</t>
<t>Number (8 bits): Indicates the total nunmber of multi stages multiplexing hierarchies which are supported or prohibited by the link port.</t>
<t>Reserve (8 bits): for future use.</t>
<t>(MSMH 1, MSMC 1), (MSMH 2, MSMC 2), ... ,(MSMH M, MSMC M): Indicates each multi stages multiplexing capability detailed information.
<list style="symbols">
<t>MSMH 1, MSMH2, ... , MSMH M (4 bits): Indicates the numbers of Multi Stages Multiplexing Hierarchies (MSMH).
<list style="symbols">
<t>MSMH = 1: It indicates ODUi is mapped into ODUk (k > i) by single stage multiplexing (e.g., ODU0-ODU3).</t>
<t>MSMH > 1: It indicates ODUi is mapped into ODUk (k > i) by multi stages multiplexing (e.g., ODU0-ODU1-ODU3).</t>
</list>
</t>
<t>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.
<figure>
<artwork align="left">
<![CDATA[
Value Type
----- ----
0000 ODU0
0001 ODU1
0010 ODU2
0011 ODU3
0100 ODU4
0101 ODU2e
0110 ODUflex
7-15 Reserved (for future use)]]>
</artwork>
</figure>
</t>
</list>
</t>
<t>The padding is used to make the Multi Stages Multiplexing Capability Descriptor sub-TLV 32-bits aligned.</t>
</list>
</t>
</section>
<section title="Latency Attribute TLV">
<figure>
<artwork align="center">
<![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]>
</artwork>
</figure>
<t>
<list style="hanging">
<t hangText="-">
Minimum Latency Value: a minimum value indicates the latency performance parameters which server layer/sub-layer LSP must meet.
</t>
<t hangText="-">
Maximum Latency Value: a maximum value indicates the latency performance parameters which server layer/sub-layer LSP must meet.
</t>
<t hangText="-">
Average Latency Value: a average value indicates the latency performance parameters which server layer/sub-layer LSP must meet.
</t>
<t hangText="-">
Latency Variation Value: a variation value indicates the latency performance parameters which server layer/sub-layer LSP must meet.
</t>
</list>
</t>
</section>
</section>
<section title="Signaling Procedure">
<t>
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.
</t>
<t>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.
</t>
</section>
<section title="Security Considerations">
<t>TBD</t>
</section>
<section title="IANA Considerations">
<t>TBD</t>
</section>
</middle>
<!--<B>~<B>~<B>~<B>~<B>~<B>~<B>~<B>~<B>~<B>~<B>~<B>~<B>~<B>~<B>~<B>~<B>~<B>~<B>~<B>~<B>~<B>~<B>~~<B>-->
<!--< >-->
<!--< BACK MATTER >-->
<!--< >-->
<!--<B>~<B>~<B>~<B>~<B>~<B>~<B>~<B>~<B>~<B>~<B>~<B>~<B>~<B>~<B>~<B>~<B>~<B>~<B>~<B>~<B>~<B>~<B>~~<B>-->
<back>
<references title="Normative References">
&RFC2119;
&RFC3209;
&RFC3471;
&RFC3473;
&RFC4203;
&RFC4206;
&RFC4655;
&RFC5212;
&RFC5440;
</references>
<references title="Informative References">
<?rfc include='reference.I-D.draft-ietf-ccamp-gmpls-mln-extensions-12'?>
<?rfc include='reference.I-D.draft-ietf-rtgwg-cl-requirement-00'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 07:28:23 |