Network Working Group X. Fu
Internet-Draft M. Betts
Intended status: Standards Track ZTE Corporation
Expires: January 13, 2011 R. Jing
X. Huo
China Telecom
Y. Xu
CATR
July 12, 2010
Framework for Multi Stages Multiplexing Configuration in G.709 Optical
Transport Network
draft-fuxh-ccamp-multi-stage-multiplex-config-fwk-01
Abstract
Interworking between regions with 1.25G TS and 2.5G TS has been
considered in G.709. Multi stages multiplexing would be desirable to
facilitate the introduction of new ODU0 and ODUflex signals to an
existing network without having to upgrade every node in the network.
So ODU0/ODUflex can be mapped into ODU1/ODU2/ODU3 and transit across
the 2.5G TS region. Multi stages multiplexing are also used to
support the multi-domain OTN applications based on carrier-Carrier,
regional-national core interconnection or network tunnels design.
This document describes the framework for multi stages multiplexing
configuration in G.709 Optical Transport Network.
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 RFC 2119 [RFC2119].
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."
Fu, et al. Expires January 13, 2011 [Page 1]
Internet-Draft Multi Stages Multiplexing Configuration July 2010
This Internet-Draft will expire on January 13, 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
(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.
Fu, et al. Expires January 13, 2011 [Page 2]
Internet-Draft Multi Stages Multiplexing Configuration July 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Multi Stages Multiplexing vs Single Stage Multiplexing . . . . 4
2.1. Bandwidth Fragmentation . . . . . . . . . . . . . . . . . 4
2.2. Integrated Line Card vs Cascade Line/Equipment . . . . . . 5
3. GMPLS and PCE Extension to Support Multi Stages
Multiplexing Configuration . . . . . . . . . . . . . . . . . . 6
3.1. Routing Extension to Support Multi Stages Multiplexing
Configuration . . . . . . . . . . . . . . . . . . . . . . 6
3.1.1. Multi Stages Multiplexing Capability . . . . . . . . . 7
3.1.2. Selection of Multi Stages Multiplexing Hierarchies . . 14
3.2. Signaling Extension to Support Multi Stages
Multiplexing Configuration . . . . . . . . . . . . . . . . 15
3.3. PCE Extension to Support Multi Stages Multiplexing
Configuration . . . . . . . . . . . . . . . . . . . . . . 15
4. Security Considerations . . . . . . . . . . . . . . . . . . . 16
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.1. Normative References . . . . . . . . . . . . . . . . . . . 16
6.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Fu, et al. Expires January 13, 2011 [Page 3]
Internet-Draft Multi Stages Multiplexing Configuration July 2010
1. Introduction
Multi stages multiplexing configuration requirement is defined in
[draft-fuxh-ccamp-multi-stage-multiplex-config-req-01] document. It
describes two typical use case of multi stages multiplexing
configuration.
The introduction of ODU0 and ODUflex to the OTN hierarchy creates the
requirement where multi stages of multiplexing would be desirable to
facilitate the introduction of these new ODU0 and ODUflex signals to
an existing 2.5G TS network without having to upgrade every node in
the network.
A second potential application for multi stages outside of an upgrade
scenario would be the carrier-carrier, regional-national core
interconnection cases or network design based on tunnels. Multi
stages multiplexing are used to support the multi-domain OTN
applications based on the tunnel design. If there are a large number
of circuits that share the same endpoints (or even part of an overall
path), it may be convenient from a management perspective to first
multiplex those ODU0, ODU1 and ODUflex into ODU2 or ODU3 to minimize
the number of connections that need to be made in intermediate nodes.
The ODU2/ODU3 effectively creates a tunnel through the ODU4 network
that the ODU0, ODU1 and ODUflex can use.
This document describes the framework for multi stages multiplex
configuration in G.709 Optical Transport Network.
2. Multi Stages Multiplexing vs Single Stage Multiplexing
2.1. Bandwidth Fragmentation
Single-stage ODU multiplexing can provide non-fragmented bandwidth,
maximizing the support of higher bit rate LO ODU signals. While two-
stage ODU multiplexing may introduce fragmented bandwidth into
smaller bandwidth subsets. Suppose 8 ODU0 service needs to be
created over ODU2 link by using ODU0-ODU1-ODU2 multiplexing.
o 1st ODU1 for 1st and 2nd ODU0 service.
o 2nd ODU1 for 3rd and 4th ODU0 service.
o 3th ODU1 for 5th and 6th ODU0 service.
o 4th ODU1 for 7th and 8th ODU0 service.
After 1st and 3rd ODU0 service is deleted and one new ODU1 service
Fu, et al. Expires January 13, 2011 [Page 4]
Internet-Draft Multi Stages Multiplexing Configuration July 2010
needs to be created, there is no any avaible TS for the ODU1 service
creation. There will be some fragmented bandwidth within one ODU2
link. If ODU0-ODU2 multiplexing is used and TSs have not to be
sequential for ODU1 service in order to prevent further bandwidth
fragmentation, the fragmentation can be avoided.
GMPLS could defragment such fragmented ODU link by using make-before-
break method, for example by moving ODU0 connections from one (half
empty) ODU1 trail to another (half empty) ODU1 trail. An operator
may have a policy that allows GMPLS to perform such defragmentation.
How to deal with defragementation is out scope of this document. But
the bandwidth fragment should not be an obstacle for the multi stages
multiplexing application.
2.2. Integrated Line Card vs Cascade Line/Equipment
Figure 1 shows two models of multi stages multiplexing. But it
doesn't going to restrict the implementation of equipment. In the
cascade equipment or line card model, it require the operator to
backhaul service to other seperate equipments or line cards which can
support the re-multiplexing in order to follow the single stage
multiplexing. So it will introduces unnecessary network complexity,
power and cost.
2/2 2/3
------
| |
|----| |----|
2/0 0/2 | |______| | 3/2 2/3
------ | | ------
| | | | | |
----| |--- ---| |----
|______| |______|
1.25G TS 2.5G TS
Cascade Equipment
2/0 0/2 2/3 3/2 2/3
______________ __________
| _ _ _ | | _ _ |
|| | | | | || || | | ||
____|| | \/ | |_| ||____|| | \/ | ||____
|| | /\ | | | || || | /\ | ||
||_| |_| |_|| ||_| |_||
|______________| |__________|
1.25G TS 2.5G TS
Fu, et al. Expires January 13, 2011 [Page 5]
Internet-Draft Multi Stages Multiplexing Configuration July 2010
Cascade Card
Figure 1
Figure 2 shows a different model of multi stages multiplexing. In
the integrated line card, it needs the multi stages multiplexing
within one single line card. One integrated equipment and line card
may be choosen to save on OPEX and CAPEX.
2/0 0/2/3 3/2 2/3
___________ __________
| _ _ | | _ _ |
|| | | | | || | | ||
____|| | \/ | | |____|| | \/ | ||____
|| | /\ | | | || | /\ | ||
||_| |_| | ||_| |_||
|___________| |__________|
1.25G TS 2.5G TS
Integrated Card
Figure 2
3. GMPLS and PCE Extension to Support Multi Stages Multiplexing
Configuration
From the perspective of Control Plane, path computation entity must
get multi stages multiplexing capability of each node to support
multi stages multiplexing for path computation. Path computation
entity can use the IGP protocol or configurations from Management
Plane to get this information. Path computation entity must select a
proper kind of multi stages multiplexing of nodes which may support
different multi stages multiplexing hierarchies along a specific end-
to-end connection. Signaling message must carry the multi stages
multiplexing hierarchy that has been determined by path computation
entity. Multi stages multiplexing for a specific service must be
configured after node receives the signaling of service creation.
The purpose of this section is to provide a framework for extensions
of the current GMPLS and PCE protocols for multi stages multiplexing
configuration in OTN network.
3.1. Routing Extension to Support Multi Stages Multiplexing
Configuration
Path computation entity needs to get the multi stages multiplexing
Fu, et al. Expires January 13, 2011 [Page 6]
Internet-Draft Multi Stages Multiplexing Configuration July 2010
capability information of nodes which are designed to support multi
stages multiplexing. Multi stages multiplexing capability
information must be advertised into topology by the IGP protocol.
LSAs which are advertised must carry multi stages multiplexing
capability information. Multi stages multiplexing capability can be
configured into nodes by Management Plane (e.g., Network Planning
Tool) or discovered within nodes based on the switching and
adaptation capability of switching fabrics and cards.
3.1.1. Multi Stages Multiplexing Capability
The content of this section describes the information needed for path
computation. In terms of Figure 3, there is a network element
between the 1.25G TS and 2.5G TS network. In order to facilitate the
introduction of new ODU0 and ODUflex signals from 1.25G TS network
(i.e., 10G network), ODU0/ODUflex can be mapped into ODU1/ODU2 first
and transit across the 2.5G TS network (i.e., 40G network).
This document does not imply restrictions to the equipment
implementation. It just gives an info model of how the multi stage
multiplexing capability could be represented. Modeling of routing
information must be independent of equipment design.
G1 of Figure 3 supports the following single stage and multi stages
multiplexing capability when signal is mapped into ODU3.
o ODU1-ODU3
o ODU2-ODU3
o ODU0-ODU1-ODU3
o ODU0-ODU2-ODU3
o ODU1-ODU2-ODU3
o ODUflex-ODU2-ODU3
G1 of Figure 3 supports the following single stage multiplexing
capability when signal is mapped into ODU2.
o ODU0-ODU2
o ODUflex-ODU2
o ODU1-ODU2
NE G1 of Figure 3 can also add or drop the STM-16 (ODU1) and 10GigE
Fu, et al. Expires January 13, 2011 [Page 7]
Internet-Draft Multi Stages Multiplexing Configuration July 2010
(ODU2).
Network Element G1
_____________________________________________________________
| ______________ ______________________________ |
| | ___ | ___ | ___ | |
| | | | | | | | | | | |
| | | | --- | | | | -------- #2 | | | |
| | | | | O | | | | | | O |-------------| | | |
| | | |--| D |-|--| |--|-| D | | | | |
| | | | | U | | | | | | U | #3 --- | | | |
| | | | | 1 | | | | | | 1 |----| | | | | |
| | | | --- | | | | -------- | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | |#4 | | | | | |
| | | | --- | | | | --- | | | | | | |
OTU2 Port1 | | | O | | O | | | D | | | O |-- | O | #1 | O | | | OTU3 Port2
1.25G TS----|--|-| D |--| D |-|--| X |--|-| D |---------| D |----| D |-|--|----2.5G TS
Network | | | U | | U | | | C | | | U | #5 | U | | U | | | Network
| | | 2 | | 0 | | | | | | 0 | | 2 | | 3 | | |
| | | | --- | | | | --- | | | | | |
| | | | | | | | | | | | | |
| | | | --- | | | | --- | | | | | |
| | | | | f | | | | | | f | | | | | | |
| | | | | l | | | | | | l | | | | | | |
| | | |--| e |-|--| |--|-| e |---------| | | | | |
| | | | | x | | | | | | x | #6 | | | | | |
| | | | --- | | | | --- | | | | | |
| | | |--------|--| |--|---------------| | | | | |
| | |___| | |___| | |___| |___| | |
| |______________| | | |______________________________| |
| ___| |___ |
| | | |
| --- --- |
| | O | | O | |
| | D | | D | |
| | U | | U | |
| | 1 | | 2 | |
| --- --- |
|_________________|_________|_________________________________|
| |
| |
Add/Drop Add/Drop
(STM-16) (10GigE)
Figure 3
Fu, et al. Expires January 13, 2011 [Page 8]
Internet-Draft Multi Stages Multiplexing Configuration July 2010
There should be some ISCDs [RFC4202][RFC4203] or IACDs
[RFC5339][draft-ietf-ccamp-gmpls-mln-extensions-12] to describe the
switching/adaptation capability of OTU2 and OTU3 TE Link. OTU2 TE
Link can directly support ODU0, ODU1, ODUflex and ODU2 switching
capability. OTU3 TE Link can directly support ODU1, ODU2 and ODU3
switching capability. OTU3 TE Link can support ODU0, ODU1 and
ODUflex by multi stages multiplexing hierarchies. In order for path
computation, following information needs to be advertised into
topology.
o ODUk Type (e.g., OTU3 and OTU2 of Figure 3).
o Tribute Slot Type: 1.25G TS or 2.5G TS.
o Supported ODUi: Max/Available/Allocated (k > i).
* Max: maximum numbers of ODUi which can be supported directly by
the ODUk link.
* Available: available numbers of ODUi which can be supported
directly by ODUk link.
* Allocated: the numbers of ODUi which has been allocated. This
information isn't necessary to be advertised. It may be
maintained in the control plane instance.
o Supported ODUflex: max/available/allocated.
* Max TSs: The maximum tribute slots that could be supported
directly for ODUflex by the ODUk (k=2, 3, 4).
* Available TSs: maximum numbers of tribute slots that are not
assigned for ODUflex.
* Allocated TSs: tribute slots that have been allocated for
ODUflex. This information isn't necessary to be advertised.
It may be maintained in the control plane instance.
We can only use ISCDs to represent single stage and multi stages
multiplexing capability. But other further information is necessary.
o Multiplexing Hierarchy Flag (MHF): single stage multiplexing or
multi stages multiplexing. When it is set to 0, ODUi (i < k) is
mapped into ODUk by single stage multiplexing. When it is set to
1, ODUi (i < k) is mapped into ODUk by multi stages multiplexing.
o Multi Stages Multiplexing Hierarchy (MSMH).
Fu, et al. Expires January 13, 2011 [Page 9]
Internet-Draft Multi Stages Multiplexing Configuration July 2010
We would have the following TE link advertisements:
OTU2 TE Link (Port1):
- ISCD 1 sub-TLV: ODUk Type = 10G (ODU2),
Tribute Slot Type = 1.25G TS,
[Max] [Available] [Allocated] [MHF] [MSMH]
ODU0 8 8 0 0 /
ODU1 4 4 0 0 /
ODU2 1 1 0 0 /
ODUflex 8 8 0 0 /
OTU3 TE Link (Port2):
- ISCD 2 sub-TLV: ODUk Type = 40G (ODU3),
Tribute Slot Type = 2.5G TS,
[Max] [Available] [Allocated] [MHF] [MSMH]
ODU3 1 1 0 0 /
#1 ODU2 4 4 0 0 /
#2 ODU1 16 16 0 0 /
- ISCD 3 sub-TLV: ODUk Type = 40G (ODU3),
Tribute Slot Type = No Meaning,
[Max] [Available] [Allocated] [MHF] [MSMH]
#4 ODU0 32 32 0 1 ODU0-ODU1-ODU3
- ISCD 4 sub-TLV: ODUk Type = 40G (ODU3),
Tribute Slot Type = No Meaning,
[Max] [Available] [Allocated] [MHF] [MSMH]
#3 ODU1 16 16 0 1 ODU1-ODU2-ODU3
#5 ODU0 32 32 0 1 ODU0-ODU2-ODU3
#6 ODUflex 32 32 0 1 ODUflex-ODU2-ODU3
If there are three 10GigE (ODU2) services and one STM-16 service
which are added into NE G1 of Figure 3 accross the OTU3 link,
following ISCDs has to be changed. There is no any adaptation
capability between ODUflex, ODU0, ODU1 and ODU2. So ODUflex, ODU0
and ODU1 can not be mapped in ODU2 in ODU3 when they are going to
across the 2.5G TS network. There is no any changing for the
adaptation capability of ODU0 being mapped in ODU1 in ODU3.
Fu, et al. Expires January 13, 2011 [Page 10]
Internet-Draft Multi Stages Multiplexing Configuration July 2010
OTU3 TE Link (Port2):
- ISCD 2 sub-TLV: ODUk Type = 40G (ODU3),
Tribute Slot Type = 2.5G TS,
[Max] [Available] [Allocated] [MHF] [MSMH]
ODU3 1 0 0 0 /
#1 ODU2 4 0 3 0 /
#2 ODU1 16 3 1 0 /
- ISCD 3 sub-TLV: ODUk Type = 40G (ODU3),
Tribute Slot Type = No Meaning,
[Max] [Available] [Allocated] [MHF] [MSMH]
#4 ODU0 32 6 0 1 ODU0-ODU1-ODU3
- ISCD 4 sub-TLV: ODUk Type = 40G (ODU3),
Tribute Slot Type = No Meaning TS,
[Max] [Available] [Allocated] [MHF] [MSMH]
#3 ODU1 16 0 0 1 ODU1-ODU2-ODU3
#5 ODU0 32 0 0 1 ODU0-ODU2-ODU3
#6 ODUflex 32 0 0 1 ODUflex-ODU2-ODU3
We could also combine ISCDs and IACDs to represent single stage and
multi stages multiplexing capability of OTU3 Port2. We would have
another TE link advertisements for single stage multiplexing. Only
ODUi which could be supported directly by ODUk TE Link is representd
in ISCD.
OTU3 TE Link (Port2):
- ISCD 1 sub-TLV: ODUk Type = 40G (ODU3),
Tribute Slot Type = 2.5G TS,
[Max] [Available] [Allocated] [MHF] [MSMH]
ODU1 16 16 0 0 /
ODU2 4 4 0 0 /
ODU3 1 1 0 0 /
In order to make path computation entity be aware of the multi stages
multiplexing capability information, following information needs to
be advertised into topology.
o Supported ODUj: max/available/allocated (k > i > j)
* Max: maximum numbers of ODUj which can be directly adapted into
ODUi.
* Available: available numvers of ODUj which can be directly
adapted into ODUi.
Fu, et al. Expires January 13, 2011 [Page 11]
Internet-Draft Multi Stages Multiplexing Configuration July 2010
* Allocated: the numbers of ODUj which has been allocated for the
adaptation. This information doesn!_t need to be advertised.
It should be stored in the control plane instance.
o Supported ODUflex: max/available/allocated.
* Max TSs: The maximum tribute slots that could be mapped into
ODUi (i=2, 3, 4).
* Available TSs: maximum numbers of tribute slots that are not
assigned for ODUflex.
* Allocated TSs: tribute slots that have been allocated for
ODUflex. This information isn't necessary to be advertised.
It may be maintained in the control plane instance.
We would have the following TE link advertisements for the adaptation
capability between different ODUk containers:
OTU3 TE Link (Port2):
Supported ODU0 which is adapted into ODU1:
- IACD 1 sub-TLV: Type of ODUi: ODU1
[Max] [Available] [Allocated]
#4 ODU0 2 2 0
Supported ODU1 which is adapted into ODU2:
- IACD 2 sub-TLV: Type of ODUi: ODU2
[Max] [Available] [Allocated]
#3 ODU1 4 4 0
Supported ODU0 which is adapted into ODU2:
- IACD 3 sub-TLV: Type of ODUi: ODU2
[Max] [Available] [Allocated]
#5 ODU0 8 8 0
Supported ODUflex which is adapted into ODU2:
- IACD 4 sub-TLV: Type of ODUi: ODU2
#6 [Max] [Available] [Allocated]
ODUflex 8 8 0
In order to reduce the information which has to be advetised into
toplogy. IACD2, IACD3 and IACD4 could be combined into one IACD
(e.g., IACD5), as ODUflex, ODU0 and ODU1 are all adapted into the
same ODU2 container.
Fu, et al. Expires January 13, 2011 [Page 12]
Internet-Draft Multi Stages Multiplexing Configuration July 2010
Supported ODUj (j=0, 1, flex) which is adapted into ODU2:
- IACD 5 sub-TLV: Type of ODUi: ODU2
[Max] [Available] [Allocated]
#3 ODU1 4 4 0
#5 ODU0 8 8 0
#6 ODUflex 8 8 0
If there are three 10GigE services and one STM-16 service which are
added into NE G1 of Figure 3 accross the OTU3 link, following IACD
and IACD has to be changed. There is no any adaptation capability
between ODUflex, ODU0, ODU1 and ODU2. So ODUflex and ODU0 can not be
mapped in ODU2 in ODU3 when they are going to across the 2.5G TS
network. There is no any changing for ISCD4 (i.e., adaptation
capability of ODU0 being mapped in ODU1 in ODU3).
OTU3 TE Link (Port2):
- ISCD 1 sub-TLV: ODUk Type = 40G (ODU3),
Tribute Slot Type = 2.5G TS,
[Max] [Available] [Allocated] [MHF] [MSMH]
ODU1 16 3 1 0 /
ODU2 4 0 3 0 /
ODU3 1 0 0 0 /
Supported ODUj (j=0, 1, flex) which is adapted into ODU2:
- IACD 5 sub-TLV: Type of ODUi: ODU2
[Max] [Available] [Allocated]
#3 ODU1 4 0 0
#5 ODU0 8 0 0
#6 ODUflex 8 0 0
The following multiplexing hierarchies matrix could be inferred by
path computation entity in terms of ISCD1, ISCD2, IACD1, IACD2, IACD3
and IACD4. So path computation entity will infer that ODU0-ODU1-
ODU2-ODU3 multi stages multplexing could be supported by the network
element. But the fact is that ODU0-ODU1-ODU2-ODU3 three stage
multiplexing hierarchy couldn't be supported within the NE G1 of
Figure 3. The constraint of prohibiting ODU0 in ODU1 in ODU2 must be
expressed in topology view and considered by path computation entity.
The allowable multi stages multiplexing hierarchies should be also
known by path computation entity.
ODU1 ODU2 ODU3
ODU0 * *
ODU1 * *
ODU2 *
ODUflex *
Fu, et al. Expires January 13, 2011 [Page 13]
Internet-Draft Multi Stages Multiplexing Configuration July 2010
3.1.2. Selection of Multi Stages Multiplexing Hierarchies
The multi stages multiplexing capability information should be
discovered/enabled by the OSS and as described in the previous point
distributed via routing. Path computation entity can get multi
stages multiplexing capability of each nodes for path computation.
It must select some proper kinds of multi stages multiplexing
hierarchies for different nodes along a specific end-to-end
connection. For example, there are two multi stages multiplexing
hierarchies for ODU0 being mapped into ODU3 in NE G1 of Figure 3
(i.e., ODU0-ODU1-ODU3 and ODU0-ODU2-ODU3). So it has to determine
which kind of multi stages multiplexing hierarchies should be used
for the ODU0 service and the type of tunnel (FA-LSP). In Figure 4,
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 | | | C | | Z |
| o-|-------------|-o o-|-----------------|-o o-|-----------|-o |
|___| OTU2 Link |_____|__| OTU3 Link |_____|_| OTU3 Link |___|
| |
ODU0-ODU1-ODU3 ODU0-ODU2
ODU0-ODU2-ODU3 ODU1-ODU2
ODUflex-ODU2-ODU3 ODUflex-ODU2
ODU1-ODU2-ODU3
ODU1-ODU3
ODU2-ODU3
Figure 4
The routing protocol should be extended to convey the multi stages
multiplexing capability information and the multi stages multiplexing
hierarchies which are supported or prohibited.
[draft-fuxh-ccamp-multi-stage-multiplex-config-ospf-01] describes
OSPF-TE extension for multi stages multiplexing configuration.
Fu, et al. Expires January 13, 2011 [Page 14]
Internet-Draft Multi Stages Multiplexing Configuration July 2010
3.2. Signaling Extension to Support Multi Stages Multiplexing
Configuration
All kinds of multi stages multiplexing hierarchies which has been
determined for all nodes along one end-to-end connection by path
computation entity must be carried with signaling message. For
example, if path computation entity select the ODU0-ODU2-ODU3 multi
stages multiplexing hierarch in Node B and C of Figure 4 for one end-
to-end ODU0 service from A to Z, the signalling message must carry
this ODU0-ODU2-ODU3 multi stages multiplexing hierarchy to inform
Node B and C. After one node which can support the flexible multi
stages multiplexing hierarchies receives the signaling message who
carries one kind of multi stages multiplexing hierarchy for it, it
must config this kind of multi stages multiplexing hierarchy to its
data plane. It needs to extend the signaling protocol to carry this
informationn. [draft-fuxh-ccamp-multi-stage-multiplex-config-rsvp-01]
describes RSVP-TE extension for multi stages multiplexing
configuration.
The ODU2 tunnel is signalled based on [RFC4328] signalling. It can
be resolved by using pre-established HO ODU2 or triggered by ODU0
connection signalling. After the ODU2 tunnel is created, one ODU2
link is added into the topology for other ODUflex/ODU0/ODU1 path
computation. When the "last" LO ODU type service (e.g. ODU0, ODU1
and ODUflex) removed, the ODU2 must be torn down and removed from the
ODU0 /ODU1/ODUflex topology; the timing for this should be set by a
policy e.g. immediately, after 10 days, or...
3.3. PCE Extension to Support Multi Stages Multiplexing Configuration
Based on the [draft-fuxh-ccamp-multi-stage-multiplex-config-ospf-01],
path computation entity can get multi stages multiplexing capability
of each nodes for path computation. Path computation entity in
Management Plane and/or Control Plane must support the path
computation by using the multi stages multiplexing capability and
supported or prohibited multi stages multiplexing hierarchies
information. It must determine some proper kinds of multi stages
multiplexing hierarchy for different nodes along the path.
A request from a PCC to a PCE MUST support the inclusion of an
optional indication of which kinds of multi stages multiplexing
hierarchy can be used for sepecific node or not. So the path
computation entity must consider these multi stage multiplexing
hierarchy constraints. In the absence of such an indication, the
default is that there is no any multi stage multiplexing hierarchy
constraint for path computation.
PCReq has a desire to be extended to carry some kindes of multi
Fu, et al. Expires January 13, 2011 [Page 15]
Internet-Draft Multi Stages Multiplexing Configuration July 2010
stages multiplexing hierarchy constraints of some specific nodes for
path computation from PCC. PCRep also has a desire to be extended to
carry all kindes of multi stages multiplexing hierarchy which have
been selected by PCE for each nodes along the path.
PCEReq
(Including or excluding list of multi stages multiplexing hierarchies)
------------------------------------------------------------
| |
|______ _\|/___
| | | |
| PCC |--------------------------------------------------| PCE |
|_______| |_______|
/|\ |
|____________________________________________________________|
PCERep
(selection of multi stages multiplexing hierarchies)
Figure 5
4. Security Considerations
The use of control plane protocols for signaling, routing, and path
computation opens an OTN to security threats through attacks on those
protocols. The data plane technology for an OTN does not introduce
any specific vulnerabilities, and so the control plane may be secured
using the mechanisms defined for the protocols discussed. For
further details of the specific security measures refer to the
documents that define the protocols ([RFC3473], [RFC4203], [RFC4205],
[RFC4204], and [RFC5440]). [GMPLS-SEC] provides an overview of
security vulnerabilities and protection mechanisms for the GMPLS
control plane.
5. IANA Considerations
TBD
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Fu, et al. Expires January 13, 2011 [Page 16]
Internet-Draft Multi Stages Multiplexing Configuration July 2010
[RFC4328] Papadimitriou, D., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Extensions for G.709 Optical
Transport Networks Control", RFC 4328, January 2006.
[RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in
Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4202, October 2005.
[RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support
of Generalized Multi-Protocol Label Switching (GMPLS)",
RFC 4203, October 2005.
[RFC5339] Le Roux, JL. and D. Papadimitriou, "Evaluation of Existing
GMPLS Protocols against Multi-Layer and Multi-Region
Networks (MLN/MRN)", RFC 5339, September 2008.
[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.
[I-D.ietf-ccamp-gmpls-g709-framework]
Zhang, F., Li, D., Li, H., Belotti, S., Han, J., Betts,
M., Grandi, P., and E. Varma, "Framework for GMPLS and PCE
Control of G.709 Optical Transport Networks",
draft-ietf-ccamp-gmpls-g709-framework-00 (work in
progress), April 2010.
[I-D.ietf-ccamp-gmpls-mln-extensions]
Papadimitriou, D., Vigoureux, M., Shiomoto, K., Brungard,
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.
6.2. Informative References
Authors' Addresses
Xihua Fu
ZTE Corporation
Email: fu.xihua@zte.com.cn
Fu, et al. Expires January 13, 2011 [Page 17]
Internet-Draft Multi Stages Multiplexing Configuration July 2010
Malcolm Betts
ZTE Corporation
Email: malcolm.betts@zte.com.cn
Ruiquan Jing
China Telecom
Email: jingrq@ctbri.com.cn
Xiaoli Huo
China Telecom
Email: huoxl@ctbri.com.cn
Yunbin Xu
CATR
Email: xuyunbin@mail.ritt.com.cn
Fu, et al. Expires January 13, 2011 [Page 18]