Multi layer implications in GMPLS controlled networks
draft-bcg-ccamp-gmpls-ml-implications-01
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Daniele Ceccarelli , Francesco Fondelli , Sergio Belotti , Dimitri Papadimitriou | ||
| Last updated | 2012-07-16 | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-bcg-ccamp-gmpls-ml-implications-01
CCAMP Working Group D. Ceccarelli, Ed.
Internet-Draft F. Fondelli
Intended status: Informational Ericsson
Expires: January 17, 2013 S. Belotti
D. Papadimitriou, Ed.
Alcatel-Lucent
July 16, 2012
Multi layer implications in GMPLS controlled networks
draft-bcg-ccamp-gmpls-ml-implications-01
Abstract
This document defines requirements and uses cases for the extension
of the OTN MLN work to MRNs. It also provides an evaluation of
already existing solutions againts new requirements.
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 January 17, 2013.
Copyright Notice
Copyright (c) 2012 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
Ceccarelli, et al. Expires January 17, 2013 [Page 1]
Internet-Draft Multi layer implications July 2012
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Applicability Scenarios . . . . . . . . . . . . . . . . . . . 3
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Missing information . . . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Ceccarelli, et al. Expires January 17, 2013 [Page 2]
Internet-Draft Multi layer implications July 2012
1. Introduction
Generalized MPLS (GMPLS) supports the control of multiple switching
technologies: packet switching, Layer-2 switching, TDM (Time-Division
Multiplexing) switching, wavelength switching, and fiber switching
([RFC3945]).
The Interface Switching Capability concept has been defined for the
advertisement of the Switching Capabilities of the different
interfaces of a node [RFC4202], while in the context of Multi Region
Networks (MRN) the Interface Adjustment Capabiltiy concept has been
introduced [RFC5339] for the advertisement of adjustment capacity
within an hybrid node.
With the introduction of G709v3 networks, a new Switching Capability
(OTN-TDM) has been defined [OSPF-OTN] and the ISCD updated in order
to cope with the OTN specific multi stage multiplexing capabilities.
The new Switching Capability Specific Information (SCSI) field
provides information about the bandwidth availability at each layer
of the OTN hierarchy and about the operations that can be performed
on the different layers, in terms of termination and switching
capabilities.
These issues have been addressed in the OTN documents within the OTN
multi layer scope but need to be extended to MRNs, where the
termination of a hierarchical LSP leads to the need of properly
managing different switching capabilities and different adaptation
functions.
Scope of this document is describing new requirements derived from
the extension of OTN MLN hierarchies to MRNs and evaluating impacts
on existing solutions.
1.1. 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].
2. Applicability Scenarios
When moving from OTN MLNs to general MRNs, the multiplexing tree
concept introduced in [OSPF-OTN] needs to be extended so to take into
account both different switching capabilities within the same muxing
tree and adaptations between client hierarchies and server
hierarchies.
Ceccarelli, et al. Expires January 17, 2013 [Page 3]
Internet-Draft Multi layer implications July 2012
In the following figure an example of muxing tree supporting TDM,
PSC, OTN-TDM and LSC hierarchies mixed together is shown.
VC-4
|
ODU1 STM-16 PSC L2SC
| | | |
| | | |
ODU2 ODU2 ODU1 |
\ \ / /
\ \ / /
\ \ / /
\ \ / /
\ \/ /
\_ _ODU3__/
|
OCh
Figure 1: Muxing tree
As it is possible to understand from the figure above, an MRN
equipment can host a variety of client-server relationships. Four
different scenarios can be identified:
- A signal type X is a client to a Signal type Y (1:1) - e.g.
Ethernet over WDM
- A signal type X is a client to a Intra switching technology
Hierarchy Y (1:N) - e.g. Ethernet over OTN
- An Intra switching technology Hierarchy X is a client to a
Signal Type Y (M:1) - e.g. ODU over WDM
- An Intra switching technology Hierarchy X is a client to an
Intra switching technology Hierarchy Y (M:N) - e.g. SDH over OTN
Being the first three scenarios a particular case of the fourth one,
in the following only the general case of M:N relationship will be
addressed.
This kind of client-server hierarchy can be achieved, depending on
the impelemntation, via single board or a cascade of them. In the
latter case boards are connected via internal links, which can be
either intra or inter switching capaility (e.g. ODU2->ODU3 or
PSC->LSC). Those links should not be modeled as external TE links,
but there is the need to advertise their characteristics and
Ceccarelli, et al. Expires January 17, 2013 [Page 4]
Internet-Draft Multi layer implications July 2012
availability in terms of bandwidth and optical parameters.
+--------------------------------------------------------+
| +------------+ Eth +------------+ |
| | | | | | |
| OTU-1 +----+ | | +----+ | |
| +----+ | | +--> + | | |
| | 8 | | | 4 | | |
| OTU-1 |ODU1+------+| |ODU2+------+| OTU-3 |
| +----+ |ODU-2 |..........>+ |ODU-3 |+----------|-->
| | +------+|Internal | +------+| |
| OTU-1| | |Physical | | | |
| +----+ | | Link + | | |
| +----+ | (OTU-2) +----+ | |
| | | | | |
| +------------+ +------------+ |
+--------------------------------------------------------+
Figure 2: Cascaded muxponder
Moreover, as described in [RFC5212], in a hybrid node there is the
need to take into account also the node's internal adjustment
capabilities between the switching technologies supported. An
example of hybrid node with different switching matrices is shown in
the following figure, where both an SDH and OTN matrix are available
and the two switching elements are internally interconnected so that
it is possible to terminate some resources (e.g. OTN interface Y1)
or provide adjustment for the SDH traffic (e.g. OTN interface Y2
toward the SDH matrix). In addition to the internal links between
matrices it is possible to have internal links between matrices and
cascaded cards for the creation of the muxing hierarchy. In the
example below both the SDH and OTN matrices are client to an
ODU2->ODU3 muxponder (through interfaces Y4 and Y5), which in turn is
client to an OCh WSS.
Ceccarelli, et al. Expires January 17, 2013 [Page 5]
Internet-Draft Multi layer implications July 2012
| 10GbE
+-------------------------+-------------+
| | |
| | |
+-+ | +---------+ | |
|X| | X1 | | | |
__+-+__|__________| \ / | | |
| ` \/ | X3 | |
| X2 | /\ '''| | ODU2 |
| |''''' / \ | | | Y6+---+ | +---------+
| | | +---+ | | +---+ | | | |
| | | |SDH| + | Y5 | | ODU3| | |
| | |__+---+__| +-----+ +----+| | |
| | | | || OTU3/OCH| +---+ |
| | | | ++----------+ |WSS| +---
| | Y4 | | || Y7 | +---+ |Y8
| | +----------+ ...... +----+| | |
+-+ | | | \ / | | ___| |+--+ | | |
|Y| | |Y2 | \/ | | | +---+|OT| | | |
+-+ | .....| /\ |Y3| | +--+ | +---------+
-------+----------+ / \ | | | |
| Y1 | .... | |
| | +---+ | | + |
| | |OTN| | | ODU2 |
| |__+---+___| |
+---------------------------------------+
Figure 3: Hybrid node with optical muxponder and different switching
matrices
3. Requirements
In order to deal with all the scenarios depiscted in the previous
sections, protocol extensions need to take into account the following
set of requirements.
1. It must be possible to identify from which branch of X to
which branch of Y the mapping is performed. Due to a restricted
connectivity to a given switching layer, not all the indicated
branches are really available. An example of such limitations can
be seen in figure Figure 3, where for example the SDH client can
be mapped only on itnerface Y5 of the muxponder board or the
10GbEth on interface Y6. In figure Figure 1 it is also possible
to see that the OTN has a hierarchy with 3 branches (i.e.
ODU1->ODU2->ODU3, ODU2->ODU3 and ODU1->ODU3) and an SDH signal can
be mapped only over the ODU2->ODU3 branch while an Ethernet one
Ceccarelli, et al. Expires January 17, 2013 [Page 6]
Internet-Draft Multi layer implications July 2012
can be mapped only on the ODU1->ODU3). So it is not eough to say
that SDH can be mapped over ODU or Eth over ODU as further info is
needed. Moreover it is also not enough to say that Eth is mapped
over ODU1 because in the same example 2 different branches have
the ODU1 as the top most layer (i.e. ODU1->ODU2->ODU3 and
ODU1->ODU3) and not both of them can support Eth mapping.
2. Adaptation information from X to Y to be used both in case of
Y being switched and X mapped over it or in case of both X and Y
being switched. Please note that more than one type of adaptation
might be availble.
3. Amount of available bandwidth in the mapping between X and Y
(as per actual IACD definition)
4. It must be possible to advertise intra-switching capability
associated to internal links. A typical case is a hierarchy
gained through the cascade of multiple cards (e.g. trasnponders,
muxponders) and the link from one board to the other one has a
given bandwidth.
5. It must be possible to advertise inter-switching capability
associated to internal links. A typical case is a M:N client-
layer hierarchy gained through the cascade of multiple cards (e.g.
SDH client to a muxponder card) and the link from one board to the
other one has a given bandwidth.
4. Evaluation
[RFC6001] defined the Interface Adjustment Capability Descriptor
(IACD) for the advertisement of internal adjustment capability of
hybrid nodes [RFC5212].
A common adjustment pool is a pool of reservable and sharable
resources that are i) allocated on demand/dynamically and ii) either
assigned to a single SC (single adjustment pool model) or multiple SC
(multiple adjustment pool model) or possibly their combination.
In the former case (single pool model), the "lower SC" value of the
IACD (associated to the adjustment pool) is set to the SC value of
ISCD sub-TLV of the interface that gets access to the adjustment pool
and the "upper" SC value of the IACD (associated to the adjustment
pool) determines the SC capability of the resource pool. In this
case the (upper) encoding is set to 0xFF. In other terms, the
capacity of the adustment pool is not directly accessible - over the
wire - by other nodes belonging to the same TE domain (assuming
homogeneous LSP encoding type along the LSP path). This model (see
Ceccarelli, et al. Expires January 17, 2013 [Page 7]
Internet-Draft Multi layer implications July 2012
Example 1) is typically used when the node matrix switching
capability is not terminating/initiating any LSP (the node only
exposes the capability associated to its I/O) but nodes part of the
same TE domain can still take into account the adjustment capacity
usage on that node.
In the latter case (multiple pool model), the "lower SC" value of the
IACD (associated to the adjustment pool) is set to the SC value of
ISCD sub-TLV of the interface(s) that gets access to the adjustment
pool and the "upper" SC value of the IACD (associated to the
adjustment pool) determines the SC capability of the adjustment pool
itself, however, this "upper SC" value is not associated to any ISCD
sub-TLV (compared to the single pool model where the "upper SC" value
corresponds to at least one of the SC value associated to the ISCD
sub-TLVs). In other terms, the (lower) SC value associated to each
adjustment pool shall be covered by at least one of the SC associated
to the ISCD sub-TLVs. This model (see Example 2) is typically used
when nodes expose their full (multi-level) grooming and initiation/
termination capacity.
Example of single pool model: in the IACD sub-TLV the "upper" SC type
= TDM/HO-SDH, and the "lower" SC type being respectively "L2SC" and
"OTH/TDM". In this example, the capacity associated to the IACD
represents the "interconnection capacity" between the interface X
(L2SC or OTH) to Y = (HO-SDH/TDM). The encoding type associated to
the upper SC is set to 0xFF.
Ceccarelli, et al. Expires January 17, 2013 [Page 8]
Internet-Draft Multi layer implications July 2012
^ ^ ^
| | |
+-------------------------------------+
| Network | | ... | |
| element | | | |
| +---------+ |
| +------| L2SC |<----+ |
| | | | | |
| | +---------+ | |
| | | |
| | +---------+ | |
| +----->| HO-SDH |-----+ |
| +------| |<----+ |
| | +---------+ | |
| | | |
| | +---------+ | |
| +----->| |-----+ |
| _ | | _ |
| / | | | | \ |
Fiber 1 | / |-----| OTH |-----| \ | Fiber 1
-----|---| |-----| |-----| |---|----
... | | |-----| |-----| |...|
-----|---| |-----| |-----| |---|----
Fiber N | \ |-----| |-----| / | Fiber N
| \_| +---------+ |_/ |
+-------------------------------------+
Figure 4: Example of single pool model
The advertisement for the node interfaces will be:
+ L2SC interfaces
- ISCD sub_TLV 1 for L2SC interface
- IACD sub_TLV 1 for L2SC to HO-SDH (1) in figure above
+ OTH inferfaces
- ISCD sub_TLV 1 for OTH interface
- IACD sub_TLV 1 for OTH to HO-SDH (2) in figure above
Example of multiple pool model: In this case we will show two
examples, the first of which does not foresee any interconnection
between the L2SC and the HO-SDH matrices, while the second one does.
Ceccarelli, et al. Expires January 17, 2013 [Page 9]
Internet-Draft Multi layer implications July 2012
In the former case there is at least one ISCD sub-TLV of SC = X
corresponding to the lower SC value (HO-SDH/TDM) of the IACD sub-TLV
associated to the first adjustment pool (HO-SDH/TDM), and one ISCD
sub-TLV of type SC = Y corresponding to the lower SC value (L2SC) of
the IACD sub-TLV associated to the second adjustment pool Y (L2SC).
In this example, the capacity associated to the IACD represents the
"interconnection capacity" between the pool of SC = X (HO-SDH/TDM) to
Y (L2SC). Each TE Link 1...N is able to get access to this
adjustment capacity.
+------------------------------------------------+
| Network |
| element |
| +---------+ |
| +---------| L2SC |<---------+ |
| | **| |** | |
| | * +---------+ * | |
| | * * | |
| | * +---------+ * | |
| | **| |** | |
| | +-------| HO-SDH |<-------+ | |
| | | | | | | |
| | | +---------+ | | |
| | | | | |
| | | +---------+ | | |
| | | | | | | |
| _ | | | | | | _ |
| / |<- | | | | +| \ |
Fiber 1 | / |<--+ | OTH | +--| \ | Fiber 1
-----|--| |-----------| |-----------| |---|----
... | | |-----------| |-----------| |...|
-----|--| |-----------| |-----------| |---|----
Fiber N | \ |-----------| |-----------| / | Fiber N
| \_| +---------+ |_/ |
+------------------------------------------------+
Figure 5: Example of multiple pool model - No interconnection between
OTH and HO-SDH
In this case the advertisement, which is the same for each of the N
TE Link is:
- ISCD sub_TLV for LSC
- ISCD sub_TLV for HO-SDH
Ceccarelli, et al. Expires January 17, 2013 [Page 10]
Internet-Draft Multi layer implications July 2012
- ISCD sub_TLV for OTH
- IACD sub_TLV for LSC to HO-SDH (starred link)
On the other side, if we consider the same scenario including the
inteconnection between the OTH and HO-SDH matrices, as shown in
figure below, the advertisement changes as follows.
+------------------------------------------------+
| Network |
| element |
| +---------+ |
| +---------| L2SC |<---------+ |
| | **| |** | |
| | * +---------+ * | |
| | * * | |
| | * +---------+ * | |
| | **| |** | |
| | +-------| HO-SDH |<-------+ | |
| | | ..| |.. | | |
| | | : +---------+ . | | |
| | | : : | | |
| | | : +---------+ : | | |
| | | : | | : | | |
| _ | | :.| |.: | | _ |
| / |<- | | | | +| \ |
Fiber 1 | / |<--+ | OTH | +--| \ | Fiber 1
-----|--| |-----------| |-----------| |---|----
... | | |-----------| |-----------| |...|
-----|--| |-----------| |-----------| |---|----
Fiber N | \ |-----------| |-----------| / | Fiber N
| \_| +---------+ |_/ |
+------------------------------------------------+
Figure 6: Example of multiple pool model - With interconnection
between OTH and HO-SDH
This time the advertisement is modified as follows:
- ISCD sub_TLV 1 for LSC
- ISCD sub_TLV 2 for HO-SDH
- ISCD sub_TLV 3 for OTH
Ceccarelli, et al. Expires January 17, 2013 [Page 11]
Internet-Draft Multi layer implications July 2012
- IACD sub_TLV 1 for LSC to HO-SDH (starred link)
- IACD sub_TLV 2 for HO-SDH to OTH (dotted link)
The IACD is the only object defined in routing for the management of
hybrid nodes. It provides the information for the forwarding/
switching capability and is used in addition to the ISCD.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lower SC | Lower Encoding| Upper SC | Upper Encoding|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Adjustment Capability-specific information |
| (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: IACD format
5. Missing information
The pieces of information needed for addressing the requirements
listed in Section 3 are:
- Adaptation information from a client to a server layer
- Connectivity constraints: need to describe optical transponder
muxing scheme with positioning and restricted connectivity in
Ceccarelli, et al. Expires January 17, 2013 [Page 12]
Internet-Draft Multi layer implications July 2012
order to provide end to end connectivity. In the example shown in
picture Figure 1, the capability of muxing an SDH hierarchy is
shown, but the SDH cannot be injected in any branch of the OTN
hierarchy. There is the need to specify that the SDH hierarchy
can be only muxed into the ODU->ODU3 branch of the OTN hierarchy
and not in all of them.
Multistage interswitching capability: The IACD already allows
advertising the multiplexing of single and multi-stage muxing
scenarios like the one in the reference muxing tree, where an SDH
hierarchy is muxed over an OTN hierarchy, which is againg muxed
over an OCh (two levels of muxing).
6. IANA Considerations
TBD
7. Contributors
TBD
8. Acknowledgements
TBD
9. References
9.1. Normative References
[OTN-FWK] F.Zhang, D.Li, H.Li, S.Belotti, D.Ceccarelli, "Framework
for GMPLS and PCE Control of G.709 Optical Transport
networks, work in progress
draft-ietf-ccamp-gmpls-g709-framework-05", September 2011.
[OTN-INFO]
S.Belotti, P.Grandi, D.Ceccarelli, D.Caviglia, F.Zhang,
D.Li, "Information model for G.709 Optical Transport
Networks (OTN), work in progress
draft-ietf-ccamp-otn-g709-info-model-02", October 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2154] Murphy, S., Badger, M., and B. Wellington, "OSPF with
Ceccarelli, et al. Expires January 17, 2013 [Page 13]
Internet-Draft Multi layer implications July 2012
Digital Signatures", RFC 2154, June 1997.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2370] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370,
July 1998.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630,
September 2003.
[RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling
in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
[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.
[RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The
OSPF Opaque LSA Option", RFC 5250, July 2008.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, July 2008.
[RFC6001] Papadimitriou, D., Vigoureux, M., Shiomoto, K., Brungard,
D., and JL. Le Roux, "Generalized MPLS (GMPLS) Protocol
Extensions for Multi-Layer and Multi-Region Networks (MLN/
MRN)", RFC 6001, October 2010.
9.2. Informative References
[G.709] ITU-T, "Interface for the Optical Transport Network
(OTN)", G.709 Recommendation (and Amendment 1),
February 2001.
[G.709-v3]
ITU-T, "Draft revised G.709, version 3", consented
by ITU-T on Oct 2009.
Ceccarelli, et al. Expires January 17, 2013 [Page 14]
Internet-Draft Multi layer implications July 2012
Authors' Addresses
Daniele Ceccarelli (editor)
Ericsson
Via Melen 77
Genova - Sestri Ponente
Italy
Email: daniele.ceccarelli@ericsson.com
Francesco Fondelli
Ericsson
Via Moruzzi 1
Pisa
Italy
Email: francesco.fondelli@ericsson.com
Sergio Belotti
Alcatel-Lucent
Via Trento, 30
Vimercate
Italy
Email: sergio.belotti@alcatel-lucent.com
Dimitri Papadimitriou (editor)
Alcatel-Lucent
Copernicuslaan 50
Antwerpen B-2018
Belgium
Email: dimitri.papadimitriou@alcatel-lucent.be
Ceccarelli, et al. Expires January 17, 2013 [Page 15]