Internet Engineering Task Force R. Martinotti
Internet-Draft D. Caviglia
Intended status: Informational Ericsson
Expires: December 9, 2011 N. Sprecher
Nokia Siemens Networks
A. D'Alessandro
A. Capello
Telecom Italia
Y. Suemura
NEC Corporation of America
June 7, 2011
Interworking between MPLS-TP and IP/MPLS
draft-martinotti-mpls-tp-interworking-02
Abstract
Purpose of this ID is to illustrate interworking scenarios between
network(s) supporting MPLS-TP and network(s) supporting IP/MPLS.
Main interworking aspects, issues and open points are highlighted.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). 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 December 9, 2011.
Copyright Notice
Copyright (c) 2011 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
Martinotti, et al. Expires December 9, 2011 [Page 1]
Internet-Draft draft-martinotti-mpls-tp-interworking-02 June 2011
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. Scope of this document . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 3
3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
5. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
6. Elements used in the figures . . . . . . . . . . . . . . . . . 5
7. Interconnectivity Options . . . . . . . . . . . . . . . . . . 6
7.1. Network Layering model . . . . . . . . . . . . . . . . . . 8
7.1.1. OAM Implication of the Layering model . . . . . . . . 8
7.1.2. Layering model control plane consideration . . . . . . 8
7.2. Network Layering scenarios . . . . . . . . . . . . . . . . 8
7.2.1. Port based transparent transport of IP/MPLS . . . . . 8
7.2.2. VLAN based transparent transport of IP/MPLS . . . . . 12
7.2.3. Port based transport of IP/MPLS with Link Layer
removal . . . . . . . . . . . . . . . . . . . . . . . 12
7.2.4. IP/MPLS / MPLS-TP hybrid edge node . . . . . . . . . . 15
7.2.5. MPLS-TP carried over IP/MPLS . . . . . . . . . . . . . 18
7.3. Network Partitioning Model . . . . . . . . . . . . . . . . 18
7.3.1. Connectivity constraints of the partitioning model . . 18
7.3.2. OAM Implications of the partitioning model . . . . . . 19
7.4. Network Partitioning scenarios . . . . . . . . . . . . . . 19
7.4.1. Border Node - Multisegment Pseudowire . . . . . . . . 20
7.4.2. Border Node - LSP stitching . . . . . . . . . . . . . 22
7.4.3. Border Link - Multisegment Pseudowire . . . . . . . . 25
7.4.4. Border Link - LSP stitching . . . . . . . . . . . . . 27
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
10. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 30
11. Security Considerations . . . . . . . . . . . . . . . . . . . 32
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
12.1. Normative References . . . . . . . . . . . . . . . . . . . 32
12.2. Informative References . . . . . . . . . . . . . . . . . . 32
Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
Martinotti, et al. Expires December 9, 2011 [Page 2]
Internet-Draft draft-martinotti-mpls-tp-interworking-02 June 2011
1. Introduction
1.1. Scope of this document
This document illustrates the most likely interworking scenarios
between MPLS-TP and IP/MPLS. For each of the examined scenarios
interworking aspects, limitations, issues and open points, with
particular focus on OAM capabilities, are provided.
The main architectural construct considered in this document foresees
PWE3 Protocol Stack Reference Model and MPLS Protocol Stack Reference
Model. See [RFC 5921] for details.
2. 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].
3. Acronyms
AC Attachment circuit
CE Customer Edge
CLI Client
CP Control Plane
DP Data Plane
ETH Ethernet MAC Layer
ETY Ethernet Physical Layer
IWF Interworking Function
LER Label Edge Router
LSP Label Switched Path
LSR Label Switch Router
Martinotti, et al. Expires December 9, 2011 [Page 3]
Internet-Draft draft-martinotti-mpls-tp-interworking-02 June 2011
MAC Media Access Control
MEP Maintenance Association End Point
MIP Maintenance Association Intermediate Point
MP Management Plane
MS-PW Multi Segment PW
NE Network Element
OAM Operations, Administration and Maintenance
PE Provider Edge
PHY Physical Layer
PSN Packet Switched Network
PW Pseudowire
SRV Server
SS-PW Single Segment PW
S-PE Switching Provider Edge
T-PE Terminating Provider Edge
4. Problem Statement
This document addresses interworking issues between MPLS-TP network
and IP/MPLS network. The network decomposition can envisage network
layering and/or network partitioning.
The presented scenarios are not intended to be comprehensive, for
instance more complex scenarios can be created composing those
described in this document.
5. Terminology
As far as this document is concerned, the following terminology is
used:
Martinotti, et al. Expires December 9, 2011 [Page 4]
Internet-Draft draft-martinotti-mpls-tp-interworking-02 June 2011
o IP/MPLS NE: a NE that supports IP/MPLS functions
o IP/MPLS Network: a network in which IP/MPLS NEs are deployed
o MPLS-TP NE: a NE that supports MPLS-TP functions
o MPLS-TP Network: a network in which MPLS-TP NEs are deployed
o Node: either MPLS-TP NE, IP/MPLS NE or CE
o Ingress direction: from client to network
o Egress direction: from network to client
For each of the scenarios described in this document, two paragraphs
may appear, one related to possible issues already envisaged by the
authors (Open Issues), the other related to aspects still left for
further study and/or definition (Open Points).
This Section provides some terminology about network layering and
partitioning. Primarily source of those definitions is [ITU-T
G.805]. Readers already familiar with these concepts can skip this
Section.
6. Elements used in the figures
A legenda of the symbols, which are most used in the following
Sections, is provided, in order to facilitate comprehension of the
scenarios.
Martinotti, et al. Expires December 9, 2011 [Page 5]
Internet-Draft draft-martinotti-mpls-tp-interworking-02 June 2011
Node:
----- Direct connection
- - - Virtual connection
..... one or more direct connections
Layers:
| Termination
+ Connection
<-> Stitching
OAM:
> or < MEP
O MIP
Figure 1
7. Interconnectivity Options
The MPLS-TP project adds dataplane OAM functionality to the MPLS tool
set that permits executive action to be delegated to the dataplane.
This provides the option of running MPLS without a control plane
while still providing carrier grade resiliency options for connection
oriented operation. Connection oriented operation alone does not
offer the scalability to offer contemporary multipoint service
solutions, but the combination of MPLS-TP connection oriented
backhaul and IP/MPLS service capabilities permits the deployment of
networks that scale significantly beyond the boundaries of current
control plane scaling.
This section describes the methods in which IP/MPLS and MPLS-TP
domains can interconnect. The network decomposition can envisage
network layering and/or network partitioning. The presented
scenarios are not intended to be comprehensive, for instance more
complex scenarios can be created composing those described in this
document. The various elements introduced in this section will be
referred to in later sections.
The following figure illustrates the Network Layering concept, as it
is described in Section 7.1:
Martinotti, et al. Expires December 9, 2011 [Page 6]
Internet-Draft draft-martinotti-mpls-tp-interworking-02 June 2011
____ ___ ___ __
_/ \___/ \ _/ \___/ \_
/ \__ / \__
/===================\===+ +====/==================\
| |___O------------------O___| |
\ /\__/_ _ _ _ _ _ _ _ _ _\__/\ /
\ ___ __ / \/ \/ \ ___ _ /
\_/ \____/ \_/ | | \_/ \___/ \_/
Layer n | | Layer n
| __ __ |
| _/ \__/ \ |
| / \__ |
| / \ |
____ +-0| |0-+
\__/ Adaptation \ /
\ __ _ /
__ \_/ \_/ \__/
\/ Termination Layer n-1
Network Layering
Figure 2
Layer n is carried over Layer n-1, via adaptation and termination
functions. Some readers will also call this concept "Overlay model".
The following figure illustrates the Network Partitioning concept, as
it is described in Section 7.3:
___ ___ ____ ____ ___ ___
_/ \___/ \ _/ \__ _/ \___/ \ _/ \__
/ \__/ \ / \__/ \_
/ \ | / \
| Sub-Network Domain 1 |+++++| Sub-Network Domain 2 |
\ / | \ /
\ __ ___ __ _/ \ ___ ___ __ _/
\_/ \____/ \___/ \____/ \_/ \____/ \___/ \___/
Network Partitioning
Figure 3
The boundary between the two subnetworks can be a link (as defined by
[ITU-T G.805]), but also a Node, which in this case SHALL be able to
Martinotti, et al. Expires December 9, 2011 [Page 7]
Internet-Draft draft-martinotti-mpls-tp-interworking-02 June 2011
handle the technologies of both subnetworks.
The two subnetworks are at the same level. Some readers will also
call this concept "Peer model".
7.1. Network Layering model
Two relationship are considered: the IP/MPLS network is carried over
the MPLS-TP one, the MPLS-TP network is carried over the IP/MPLS one.
This version of the draft focuses on the former relationship. In the
MPLS-TP architecture, the pseudo wire is the primary unit of carriage
of non-MPLS-TP payloads. This provides a clean demarcation between
MPLS-TP operations and transported payloads.
7.1.1. OAM Implication of the Layering model
The overlay model has the virtue of uniform deployment of OAM
capabilities and encapsulations at all MIPs and MEPs at a given layer
in the label stack. The IP/MPLS architecture does include OAM
transactions originated by MIPs so the layer interworking function
for MPLS-TP servers is simplified.
7.1.2. Layering model control plane consideration
The interworking between an IP/MPLS domain and an MPLS-TP domain
highly depends on the implemented model (i.e. layering or
partitioning) and different scenarios can be implemented depending on
a number of different aspects.
In the case of layering model, the first aspect consists on the
provisioning of the LSP at the N-1 layer (MPLS-TP layer). Two
possible scenarios are foreseen: pre-configuration of the MPLS-TP LSP
or induced provisioning. The pre-configuration of the MPLS-TP LSP
can be performed either manually via NMS or via the MPLS-TP control
plane signaling and the MPLS-TP LSP can be exported to the IP/MPLS
domain as a forwarding adjacency. On the other side the signaling
messages at the IP/MPLS layer, upon reaching the border of the
MPLS-TP domain, can induce the signaling of the MPLS-TP LSP via
RSVP-TE. Other use cases depend on how the IP/MPLS is carried over
the MPLS-TP domain and are analyzed scenario by scenario in the
following sections.
7.2. Network Layering scenarios
7.2.1. Port based transparent transport of IP/MPLS
This scenario foresees an IP/MPLS network carried over an MPLS-TP
network. The selection of the route over the MPLS-TP network is done
Martinotti, et al. Expires December 9, 2011 [Page 8]
Internet-Draft draft-martinotti-mpls-tp-interworking-02 June 2011
on a per port basis. The interworking is done via Link Layer (e.g.
Ethernet) encapsulation in PW over MPLS-TP (as per PWE3 Protocol
Stack Reference Model). MPLS-TP LSPs are pre-configured with respect
to IP/MPLS LSPs and IP/MPLS LSRs may be seen one hop away.
The following figure illustrates the functional interworking among
the networks:
Networks:
Customer Network
+---+ - - - - - - - - - - - - - - - - - - - - - - - - - +---+
| _________________________________________________ |
|/ IP/MPLS Network \|
+---------------+ - - - - - - - - - +---------------+
\______________|___________________|______________/
| _________________ |
|/ MPLS-TP Network \|
+-------------------+
^ \_________________/
PW emulation (VPWS)
Nodes:
+++++ +++++
+ 1 +----+ - - - - - - - - - - - - - - - - - - - - - - - +----+ 9 +
+++++ | | +++++
CE +++++ +++++ +++++ +++++ CE
+ 2 +...+ 3 +-----+- - - - - - - -+-----+ 7 +...+ 8 +
+++++ +++++ | | +++++ +++++
LER LSR +++++ +++++ +++++ LSR LER
PE CE + 4 +...+ 5 +...+ 6 + PE
+++++ +++++ +++++
LER LSR LER
PE PE
Port based transparent transport - Networks view
Figure 4
The LSR 3 and 7 are one hop away from the IP/MPLS layer point of
view, CP/MP of IP/MPLS is transparently transported by MPLS-TP
network.
In case the Link Layer is Ethernet, the service provided by the
MPLS-TP network could be an E-Line service realized via VPWS. The
LER4 and 6 do not need to know that above the Ethernet layer there is
an MPLS LSP.
Martinotti, et al. Expires December 9, 2011 [Page 9]
Internet-Draft draft-martinotti-mpls-tp-interworking-02 June 2011
7.2.1.1. OAM Considerations
The following figure illustrates the stacking relationship among the
technology layers and OAM relationship among the networks:
Layers:
|--------+----------------------CLI----------------------+--------|
|--SRV--| |--------------------(PW)---------------------| |--SRV--|
|------+--------------LSP--------------+------|
|-SRV-| |------+------SRV------+------| |-SRV-|
|-PHY-| |------PW-----| |-PHY-|
|--LSP-+------|
|-SRV-| |-SRV-|
OAM:
(5) >------O-----------------------------O------< LSP
(4) >---------------------------< SECTION
(3) >-----------< PW
(2) >-----O-----< LSP
(1) >--< >...< >---< >...< >...< >---< >...< >--< PHY
Nodes:
+++++ +++++ +++++ +++++ +++++ +++++ +++++ +++++ +++++
+ 1 +--+ 2 +...+ 3 +---+ 4 +...+ 5 +...+ 6 +---+ 7 +...+ 8 +--+ 9 +
+++++ +++++ +++++ +++++ +++++ +++++ +++++ +++++ +++++
CE LER LSR LER LSR LER LSR LER CE
Port based transparent transport - Layers and OAM view
Figure 5
Several levels of OAM are shown in the previous figure, these are not
comprehensive and any subset of them MAY be configured in a network.
A brief description of the different levels is provided:
(5) Edge-to-Edge MPLS OAM on IP/MPLS network (at LSP level)
(4) Section OAM on IP/MPLS network
(3) Edge-to-Edge MPLS-TP OAM on MPLS-TP network (at PW level)
(2) Edge-to-Edge MPLS-TP OAM on MPLS-TP network (at LSP level)
Martinotti, et al. Expires December 9, 2011 [Page 10]
Internet-Draft draft-martinotti-mpls-tp-interworking-02 June 2011
(1) Physical level OAM (MAY be of several kinds)
In case of fault detected at the MPLS-TP LSP (2) level, the
corresponding server MEP asserts a signal fail condition and notifies
that to the co-located MPLS-TP client/server adaptation function
which then generates OAM packets with AIS information in the
downstream direction to allow the suppression of secondary alarms at
the MPLS-TP MEP in the client (sub-) layer, which in this example
correspond to PW layer (3).
Note that the OAM layers not directly related to MPLS-TP network have
been reported just for completeness of the scenario; however their
behavior and interworking are out of scope of this document. For
MPLS-TP Alarm reporting detailed description, please refer to
[draft-ietf-mpls-tp-oam-framework].
7.2.1.2. Control Plane considerations
In this case the interconnection between the IP/MPLS domain and the
MPLS-TP domain consists of a link. This does not allow a transparent
transport of the IP control messages (e.g. LDP) over the MPLS-TP
LSPs due to the fact that the egress node of the MPLS-TP domain is
not able to route IP packets on its interfaces. The IP control
messages need to be carried over an Ethernet frame over a PWE3 before
being injected into the MPLS-TP LSP. In other words they are
forwarded with two labels, the PWE3 one (S=0) and the LSP one (S=1).
The IP control message, upon reaching the egress LER of the MPLS-TP
domain, can be correctly forwarded to the ingress node of the IP/MPLS
domain.
7.2.1.3. Services view
There are two service models supported by the overlay model when
combined with Ethernet PWs. The first is simple p2p encapsulation
and transport of all traffic presented to the MPLS-TP on a given
interface. This is of limited utility due to the number of ports
required to achieve the desired level of network interconnect across
the MPLS-TP core.
The second is that the MPLS-TP LER maps VLANs to distinct PWs such
that multiple IP/MPLS adjacencies can be supported over each
interface between the IP/MPLS LSR and the MPLS-TP LER. This
potentially can require a large number of IP/MPLS adjacencies
overlaying the core.
In both cases the service can be unprotected or protected.
Martinotti, et al. Expires December 9, 2011 [Page 11]
Internet-Draft draft-martinotti-mpls-tp-interworking-02 June 2011
7.2.1.4. Resiliency considerations
In the scenario where the service is unprotected, resiliency is fully
delegated to the IP/MPLS network, which will depend on a combination
of routing convergence and/or FRR to maintain service. This will be
at the expense of routing stability.
A protected service can offer significant improvements in routing
stability with the exception that the link between the IP/MPLS LSRs
and the MPLS-TP LERs and the MPLS-TP LERs themselves are single
points of failure. There is an advantage in that the single points
of failures are adjacent to the MPLS LSRs such that there is a high
probability of such failures manifesting themselves immediately in
the form of a physical layer loss-of-signal failure and thus
accelerating recovery. Multiple failure scenarios may also result in
the IP/MPLS overlay having to take action to recover connectivity but
this would be gated by whatever OAM detection mechanisms were
employed by the IP/MPLS layer as there is no equivalent of MPLS-TP
LDI across the interconnect interface.
7.2.2. VLAN based transparent transport of IP/MPLS
This scenario is analogous to the previous one. The interconnection
between the IP/MPLS LSRs and the MPLS-TP PEs is done via .1Q Tagged
Ethernet, and VLANs are used to select the routes over the p2p
Ethernet connectivity services over MPLS-TP (VPWS). The interworking
is done via Ethernet encapsulation in PW over MPLS-TP (as per PWE3
Protocol Stack Reference Model). This VLAN based interconnection may
be used in order to reduce the number of physical interfaces between
the two networks. The same considerations of previous scenarios
apply.
7.2.3. Port based transport of IP/MPLS with Link Layer removal
This scenario foresees an IP/MPLS network carried over an MPLS-TP
network. The selection of the route over the MPLS-TP network is done
on a per port basis. The physical interface between the IP/MPLS and
the MPLS-TP network may be of different kind (e.g. Ethernet, POS);
the interworking is done via Link Layer removal and client packet
(MPLS and IP) encapsulation in PW over MPLS-TP (as per PWE3 Protocol
Stack Reference Model). MPLS-TP LSPs are pre-configured with respect
to IP/MPLS LSPs and are seen as routing adjacencies by the IP/MPLS
network.
The following figure illustrates the functional interworking among
the networks:
Martinotti, et al. Expires December 9, 2011 [Page 12]
Internet-Draft draft-martinotti-mpls-tp-interworking-02 June 2011
Networks:
Customer Network
+---+ - - - - - - - - - - - - - - - - - - - - - - - - - +---+
| _________________________________________________ |
|/ IP/MPLS Network \|
+---------------+ - - - - - - - - - +---------------+
\______________|___________________|______________/
| _________________ |
|/ MPLS-TP Network \|
+-------------------+
^ \_________________/
PW emulation
Nodes:
+++++ +++++
+ 1 +----+ - - - - - - - - - - - - - - - - - - - - - - - +----+ 9 +
+++++ | | +++++
CE +++++ +++++ +++++ +++++ CE
+ 2 +...+ 3 +-----+- - - - - - - -+-----+ 7 +...+ 8 +
+++++ +++++ | | +++++ +++++
LER LSR +++++ +++++ +++++ LSR LER
PE CE + 4 +...+ 5 +...+ 6 + PE
+++++ +++++ +++++
LER LSR LER
PE PE
Port based transport with Link Layer removal - Networks view
Figure 6
The LSR 3 and 7 are one hop away from the IP/MPLS layer point of
view.
The service provided by the MPLS-TP network is p2p; client traffic is
separated on a per port basis, so that (for example) all traffic
coming from LSR 3 on the interface to LER 4 is transparently
transported via LER 6 to LSR 7 and viceversa. The client traffic to
be encapsulated is both MPLS packets (DP) and IP packets (DP, CP and
MP). The encapsulation may be performed via PWs, that is, one PW is
needed for MPLS and one for IP between any given port pair or
directly using the LSP label stacking. The encapsulation via PW is
is required such that the IP/MPLS section preserves PHY like
properties and to operationally isolate TP and IP/MPLS operation
(e.g. reserved label handling link GAL and Router Alert).
Martinotti, et al. Expires December 9, 2011 [Page 13]
Internet-Draft draft-martinotti-mpls-tp-interworking-02 June 2011
7.2.3.1. OAM considerations
The following figure illustrates the stacking relationship among the
technology layers and OAM relationship among the networks:
Layers:
|--------+----------------------CLI----------------------+--------|
|--SRV--| |--------------------(PW)---------------------| |--SRV--|
|------+--------------LSP--------------+------|
|-SRV-| |-SRV-| |---PW--------| |-SRV-| |-SRV-|
|--LSP-+------|
|-SRV-| |-SRV-|
OAM:
(5) >------O-----------------------------O------< LSP
(4) >---------------------------< SECTION
(3) >-----------< PW
(2) >-----O-----< LSP
(1) >---< >---< >---< >...< >...< >---< >---< >---< PHY
Nodes:
+++++ +++++ +++++ +++++ +++++ +++++ +++++ +++++ +++++
+ 1 +--+ 2 +...+ 3 +---+ 4 +...+ 5 +...+ 6 +---+ 7 +...+ 8 +--+ 9 +
+++++ +++++ +++++ +++++ +++++ +++++ +++++ +++++ +++++
CE LER LSR LER LSR LER LSR LER CE
Port based transport with Link Layer removal - Layers and OAM view
Figure 7
Several levels of OAM are possible, a subset of them is shown in the
previous figure, however these are not comprehensive, any subset of
them MAY be configured in a network. A brief description of the
levels is provided:
(5) Edge-to-Edge MPLS OAM on IP/MPLS network (at LSP level)
(4) Section MPLS OAM
(3) Edge-to-Edge MPLS-TP OAM on MPLS-TP network (at PW level)
(2) Edge-to-Edge MPLS-TP OAM on MPLS-TP network (at LSP level)
Martinotti, et al. Expires December 9, 2011 [Page 14]
Internet-Draft draft-martinotti-mpls-tp-interworking-02 June 2011
(1) Physical level OAM (MAY be of several kinds)
7.2.3.2. Control Plane considerations
In the case of transparent transport of the IP/MPLS over the MPLS-TP
domain there are no differences, from a control plane point of view,
with respect to the case of Ethernet encapsulation over MPLS-TP.
Same considerations carried out in section 5.1.3.1.1.2 apply to this
section.
7.2.3.3. Services view
The service model for the transparent transport mode is simple p2p
encapsulation andtransport of all traffic presented to the MPLS-TP on
a given interface. This is of limited utility due tothe number of
ports required to achieve the desired level of network interconnect
across the MPLS-TP core. It would potentially also requires a
correspondingly high number of IP/MPLS adjacenciesto overlay the
core.
The service can be unprotected or protected.
7.2.3.4. Resiliency considerations
The resiliency considerations are the same as for the overlay model.
7.2.4. IP/MPLS / MPLS-TP hybrid edge node
In this scenario the physical interface between the IP/MPLS and the
MPLS-TP network is generic and may be other than Ethernet (e.g.
POS); the interworking is done via client LSP packet encapsulation as
per MPLS labeled or IP traffic over MPLS-TP as per RFC 5921. MPLS-TP
LSPs are pre-configured with respect to IP/MPLS LSPs and are seen as
routing adjacencies between the hybrid edge nodes by the IP/MPLS
network.
The service that is offered to the IP/MPLS network is that of a
multi-point MPLS VPN.
The following figure illustrates the functional interworking among
the networks.
Martinotti, et al. Expires December 9, 2011 [Page 15]
Internet-Draft draft-martinotti-mpls-tp-interworking-02 June 2011
Networks:
Customer Network
+---+ - - - - - - - - - - - - - - - - - - - - - - - - - +---+
| _________________________________________________ |
|/ IP/MPLS Network \|
+---------------+ - - - - - - - - - +---------------+
\______________|___________________|______________/
| _________________ |
|/ MPLS-TP Network \|
+-------------------+
\_________________/
Nodes:
+++++ +++++
+ 1 +----+ - - - - - - - - - - - - - - - - - - - - - - - +----+ 9 +
+++++ | | +++++
CE +++++ +++++ +++++ +++++ +++++ +++++ CE
+ 2 +...+ 3 +---+ +- - - - - -+ +---+ 7 +...+ 8 +
+++++ +++++ + + + + +++++ +++++
LER LSR +LSR+ +++++ +LSR+ LSR LER
PE + 4 +...+ 5 +...+ 6 + PE
+++++ +++++ +++++
LER LSR LER
IP/MPLS encapsulation over MPLS-TP - Networks view
Figure 8
The Node 4 and 6 in the above figure act as dual function:
o LSR of client IP/MPLS network
o LER of server MPLS-TP subnetwork
7.2.4.1. OAM considerations
The following figure illustrates the stacking relationship among the
technology layers and OAM relationship among the networks:
Martinotti, et al. Expires December 9, 2011 [Page 16]
Internet-Draft draft-martinotti-mpls-tp-interworking-02 June 2011
Layers:
|--------+----------------------CLI----------------------+--------|
|--SRV--| |--------------------(PW)---------------------| |--SRV--|
|------+-------+------LSP------+-------+------|
|-SRV-| |-SRV-| |-LSP--+------| |-SRV-| |-SRV-|
|-SRV-| |-SRV-|
OAM:
(3) >--------------O-------------O--------------< LSP
(2) >-----O-----< LSP
(1) >---< >---< >---< >...< >...< >---< >---< >---< PHY
Nodes:
+++++ +++++ +++++ +++++ +++++ +++++ +++++ +++++ +++++
+ 1 +--+ 2 +...+ 3 +---+ 4 +...+ 5 +...+ 6 +---+ 7 +...+ 8 +--+ 9 +
+++++ +++++ +++++ +++++ +++++ +++++ +++++ +++++ +++++
CE LER LSR LER LSR LER LSR LER CE
IP/MPLS encapsulation over MPLS-TP - Layers and OAM view
Figure 9
Several levels of OAM are possible, a subset of them is shown in the
previous figure, however these are not comprehensive, any subset of
them MAY be configured in a network. A brief description of the
levels is provided:
(3) Edge-to-Edge MPLS OAM on IP/MPLS network (at LSP level)
(2) Edge-to-Edge MPLS-TP OAM on MPLS-TP network (at LSP level)
(1) Physical level OAM (MAY be of several kinds)
7.2.4.2. Control Plane considerations
This case is different from the previous two because the
interconnection between the IP/MPLS domain and the MPLS-TP domain
consists of a node. This lead to the fact that IP control messages
do not need to be carried over a PWE3 along the MPLS-TP domain but
can be directly carried over an LSP. In other words they are
forwarded with a single LSP label (S=1) and , upon reaching the
hybrid node between the MPLS-TP domain and the next IP/MPLS domain ,
the signaling can be carried on.
7.2.4.3. Services view
The service model for the hybrid edge node model is that the MPLS-TP
network appears to the IP/MPLS network as a complete IP/MPLS
Martinotti, et al. Expires December 9, 2011 [Page 17]
Internet-Draft draft-martinotti-mpls-tp-interworking-02 June 2011
subnetwork. This has the virtue of collapsing the number of IP/MPLS
adjacencies required to overlay the core.
The service can be unprotected or protected. And the protection can
be a combination of MPLS-TP resiliency and IP/MPLS recovery actions.
7.2.4.4. Resiliency considerations
The resiliency considerations are similar to that of the overlay
model. However the extension of the control plane to the hybrid node
means the lack of a dataplane LDI equivalent is mitigated, the IP/
MPLS domain having been extended to reach the MPLS-TP OAM domain such
that LDI indications from core failures can interwork directly the
the control plane and accelerate recovery actions.
7.2.5. MPLS-TP carried over IP/MPLS
TODO
7.3. Network Partitioning Model
In the rest of this Section the following assumptions apply:
o Customer network is carried partly over IP/MPLS subnetwork (e.g.
via PW encapsulation) and partly over MPLS-TP subnetwork.
o An example of server layer of MPLS is Ethernet.
For the purposes of this Section, MPLS-TP subnetwork is deployed
between a CE and an IP/MPLS subnetwork. Other kinds of deployment
are possible (not shown in this document), for instance:
o More than two subnetworks are deployed between the CEs
o MPLS-TP can be deployed between two subnetworks
7.3.1. Connectivity constraints of the partitioning model
The partitioning model is constrained to interconnecting LSPs or PWs
with common behavioral characteristics. As MPLS-TP is constrained to
connection oriented behavior the portion of the LSP that transits an
IP/MPLS subnetwork will need to be effectively constrained to the
same profile, that is connection oriented, and no PHP or merging. No
ECMP or transit of LAG cannot be guaranteed which means OAM fate
sharing may not exist in IP/MPLS subnetworks and the end-to-end OAM
may only serve to coordinate dataplane resiliency actions between
MEPs with respect to faults in the MPLS-TP subnetworks.
Martinotti, et al. Expires December 9, 2011 [Page 18]
Internet-Draft draft-martinotti-mpls-tp-interworking-02 June 2011
7.3.2. OAM Implications of the partitioning model
The partitioning model requires the concatenations of path segments
that do not necessarily have common OAM components and have a number
of possible implementations. At the simplest level configuration of
common OAM capabilities and encapsulation between the MEPs in the MEG
is required. The set that is common to the MEPs in the MEG may not
necessarily be supported by the MIPs, and knowldege of MIP capability
will not figure into MEP neogitation, so the MEPs may select a common
mode that is not common with that supported by the MIPs.
The primary consequence being that MPLS-TP MIP originated
transactions, or messages targeted to MIPs using MPLS-TP
encapsulations will not be guaranteed to provide a uniform quality of
information as not all MIPs will support MPLS-TP OAM extensions, and
as noted will not participate in MEP-MEP configuration or
negotiation.
This means that GAL encapsulated OAM may only serve to coordinate
dataplane resiliency actions between MEPs with respect to faults in
the MPLS-TP subnetworks and faults in the IP/MPLS subnetwork are
recovered by IP/MPLS mechanisms (e.g. FRR). Edge to edge monitoring
of MPLS/MPLS-TP networks may be implemented using an edge to edge LSP
OAM/PW OAM, in order not to need a gateway/translation function on
the border node between the two domains.
7.4. Network Partitioning scenarios
The main features to be taken into account in deploying a partitioned
network are the following:
o Border Node or Border Link
o MultiSegment Pseudowire or LSP Stitching
o Network Interworking
o End-to-End OAM support
o Interaction between DP of IP/MPLS and DP of MPLS-TP
o Interaction between CP of IP/MPLS and MP of MPLS-TP
o Interaction between CP of IP/MPLS and CP of MPLS-TP
o Interaction between MP of IP/MPLS and MP of MPLS-TP
Martinotti, et al. Expires December 9, 2011 [Page 19]
Internet-Draft draft-martinotti-mpls-tp-interworking-02 June 2011
7.4.1. Border Node - Multisegment Pseudowire
The following figure illustrates the functional interworking among
the networks:
Networks:
Customer Network
+---+ - - - - - - - - - - - - - - - - - +---+
| _______________ _______________ |
|/ IP/MPLS Net. \ / MPLS-TP Net. \|
+-----------------+-----------------+
^ \_______________/ \_______________/
PW emulation
PWs:
|-------------MS-PW-------------|
|---------------|---------------|
^ ^
PW segments
Nodes:
+++++ +++++
+ 1 +----+- - - - - - - - - - - - - - - -+----+ 7 +
+++++ | | +++++
CE +++++ +++++ +++++ +++++ +++++ CE
+ 2 +...+ 3 +---+ 4 +...+ 5 +...+ 6 +
+++++ +++++ +++++ +++++ +++++
LER LSR LER LSR LER
T-PE S-PE T-PE
Border Node - Multisegment Pseudowire - Networks and PWs view
Figure 10
7.4.1.1. OAM considerations
The following figure illustrates the stacking relationship among the
technology layers and OAM relationship among the networks:
Martinotti, et al. Expires December 9, 2011 [Page 20]
Internet-Draft draft-martinotti-mpls-tp-interworking-02 June 2011
Layers:
|--------+--------------CLI--------------+--------|
|--SRV--| |---------PW---+--------------| |--SRV--|
|-LSP--+------| |--LSP-+------|
|-SRV-| |-SRV-| |-SRV-| |-SRV-|
OAM:
(3) >-------------O-------------< MS-PW
(2) >-----O-----< >-----O-----< LSP
(1) >--< >...< >---< >...< >...< >--< PHY
Nodes:
+++++ +++++ +++++ +++++ +++++ +++++ +++++
+ 1 +--+ 2 +...+ 3 +---+ 4 +...+ 5 +...+ 6 +--+ 7 +
+++++ +++++ +++++ +++++ +++++ +++++ +++++
CE LER LSR LER LSR LER CE
Border Node - Multisegment Pseudowire - Layers and OAM view
Figure 11
Several levels of OAM are possible, a subset of them is shown in the
previous figure, however these arenot comprehensive, any subset of
them MAY be configured in a network. A brief description of the
different levels is provided:
(3) Edge-to-Edge MPLS/MPLS-TP OAM on whole network (at PW level)
(2) Edge-to-Edge MPLS OAM and Edge-toEdge MPLS-TP OAM on each
network partition respectively (at LSPlevel)
(1) Physical level OAM (MAY be of several kind)
Open Points:
o Interworking between LSP OAM (2) and MS-PW OAM (3) is still to be
cleared/defined
o Edge-to-Edge MS-PW OAM (3) must be configured on different
subnetworks
7.4.1.2. Control Plane considerations
TODO
Martinotti, et al. Expires December 9, 2011 [Page 21]
Internet-Draft draft-martinotti-mpls-tp-interworking-02 June 2011
7.4.1.3. Services view
The generalized service model for all partitioning models is a p2p
connection for the PW client.
7.4.1.4. Resiliency considerations
The PW can be configured to be protected or unprotected at the PW
layer. If it is unprotected it is dependent on the underlying
domains (MPLS-TP or IP/MPLS) resiliency mechanisms to offer
subnetwork protection, but the S-PE is a single point of failure. A
protected PW can be set up such that the working and protection PWs
traverse physically diverse S-PEs.
Implementing E2E protection at the PW layer requires CC flows on the
PW which for large numbersof PWs may have scaling implications.
When the PW is protected, the border node as an MS-PW stitching point
permits the interworking of MPLS-TP fault indications with the PW
signaling in the IP/MPLS domain such that fast E2E protection
switching can be coordinated without requiring fast CC/CV OAM flows
in the PW layer.
7.4.2. Border Node - LSP stitching
The following figure illustrates the functional interworking among
the networks:
Martinotti, et al. Expires December 9, 2011 [Page 22]
Internet-Draft draft-martinotti-mpls-tp-interworking-02 June 2011
Networks:
Customer Network
+---+ - - - - - - - - - - - - - - - - - +---+
| _______________ _______________ |
|/ IP/MPLS Net. \ / MPLS-TP Net. \|
+-----------------+-----------------+
^ \_______________/ \_______________/
PW emulation
PWs:
|-------------SS-PW-------------|
Nodes:
+++++ +++++
+ 1 +----+- - - - - - - - - - - - - - - -+----+ 9 +
+++++ | | +++++
CE +++++ +++++ +++++ +++++ +++++ CE
+ 2 +...+ 3 +---+ 4 +...+ 5 +...+ 6 +
+++++ +++++ +++++ +++++ +++++
LER LSR LER LSR LER
PE PE
Border Node - LSP stitching - Networks and PWs view
Figure 12
The following figure illustrates the stacking relationship among the
technology layers and OAM relationship among the networks:
Martinotti, et al. Expires December 9, 2011 [Page 23]
Internet-Draft draft-martinotti-mpls-tp-interworking-02 June 2011
Layers:
|--------+--------------CLI--------------+--------|
|--SRV--| |--------------PW-------------| |--SRV--|
|------+-S-LSP<->S-LSP-+------|
|-SRV-| |-SRV-| |-SRV-| |-SRV-|
OAM:
(4) >---------------------------< PW
(3) >-------------O-------------< LSP
(2) >-----O-----< >-----O-----< TCM
(1) >--< >...< >---< >...< >...< >--< PHY
Nodes:
+++++ +++++ +++++ +++++ +++++ +++++ +++++
+ 1 +--+ 2 +...+ 3 +---+ 4 +...+ 5 +...+ 6 +--+ 7 +
+++++ +++++ +++++ +++++ +++++ +++++ +++++
CE LER LSR LER LSR LER CE
Border Node - LSP stitching - Layers and OAM view
Figure 13
Note: in this case a SS-PW extends over the subnetworks as the
stitched LSP does. TCM can be used to monitor the LSP segments.
Several levels of OAM are possible, a subset of them is shown in the
previous figure, however these are not comprehensive, any subset of
them MAY be configured in a network. A brief description of the
different levels is provided:
(4) Edge-to-Edge MPLS/MPLS-TP OAM on whole network (at PW level)
(3) Edge-to-Edge MPLS/MPLS-TP OAM on whole network (at LSP level)
(2) Edge-to-Edge MPLS OAM and Edge-toEdge MPLS-TP OAM on each
network partition respectively (at TCM level)
(1) Physical level OAM (MAY be of several kind)
Open Points:
o Edge-to-Edge LSP OAM (3) must be configured on different
subnetworks
o Edge-to-Edge PW OAM (4) must be configured on different
subnetworks
Martinotti, et al. Expires December 9, 2011 [Page 24]
Internet-Draft draft-martinotti-mpls-tp-interworking-02 June 2011
o Interworking between TCM OAM (2) and LSP OAM (3) is still to be
cleared/defined
7.4.3. Border Link - Multisegment Pseudowire
The following figure illustrates the functional interworking among
the networks:
Networks:
Customer Network
+---+ - - - - - - - - - - - - - - - - - -+---+
| ___________ ______________ |
|/IP/MPLS N. \ / MPLS-TP N. \|
+-------------+-----+----------------+
^ \___________/ \______________/
PW emulation
PWs:
|------------MS-PW--------------|
|-----------|-----|-------------|
^ ^ ^
PW segments
Nodes:
+++++ +++++
+ 1 +----+- - - - - - - - - - - - - - - -+----+ 6 +
+++++ | | +++++
CE +++++ +++++ +++++ +++++ CE
+ 2 +.....+ 3 +-----+ 4 +.......+ 5 +
+++++ +++++ +++++ +++++
LER LER LER LER
T-PE S-PE S-PE T-PE
Border Link - Multisegment Pseudowire - Networks view
Figure 14
7.4.3.1. OAM considerations
The following figure illustrates the stacking relationship among the
technology layers and OAM relationship among the networks:
Martinotti, et al. Expires December 9, 2011 [Page 25]
Internet-Draft draft-martinotti-mpls-tp-interworking-02 June 2011
Layers:
|--------+-------------CLI---------------+--------|
|--SRV--| |--------+----PW---+----------| |--SRV--|
|--LSP--| |--LSP--| |---LSP---|
|- SRV -| |--SRV--| |- -SRV- -|
OAM:
(3) >-------O---------O---------< MS-PW
(2) >-----< >-----< >-------< LSP
(1) >--< >.....< >-----< >.......< >--< PHY
Nodes:
+++++ +++++ +++++ +++++ +++++ +++++
+ 1 +--+ 2 +.....+ 3 +-----+ 4 +.......+ 5 +--+ 6 +
+++++ +++++ +++++ +++++ +++++ +++++
CE LER LER LER LER CE
Border Link - Multisegment Pseudowire - Layers and OAM view
Figure 15
Several levels of OAM are possible, a subset of them is shown in the
previous figure, however these are not comprehensive, any subset of
them MAY be configured in a network. A brief description of the
different levels is provided:
(3) Edge-to-Edge MPLS/MPLS-TP OAM on whole network (at PW level)
(2) Edge-to-Edge MPLS OAM, Border MPLS OAM and Edge-toEdge MPLS-TP
OAM on each network partition respectively (at LSP level)
(1) Physical level OAM (MAY be of several kinds)
Open Points:
o Interworking between LSP OAM (2) and MS-PW OAM (3) is still to be
cleared/defined
o LSP between Node 3 and 4 could be avoided, however in this case PW
over Ethernet should be specified.
o Edge-to-Edge MS-PW OAM (3) must be configured on different
subnetworks
Martinotti, et al. Expires December 9, 2011 [Page 26]
Internet-Draft draft-martinotti-mpls-tp-interworking-02 June 2011
7.4.3.2. Control Plane considerations
TODO
7.4.3.3. Services view
The generalized service model for all partitioning models is a p2p
connection for the PW client.
7.4.3.4. Resiliency considerations
The PW can be configured to be protected or unprotected at the PW
layer. If it is unprotected it is dependent on the underlying
domains (MPLS-TP or IP/MPLS) resiliency mechanisms to offer
subnetwork protection, but the border S-PEs and border link are all
single points of failure. A protected PW can be set up such that the
working and protection PWs traverse physically diverse border links.
Implementing E2E protection at the PW layer requires CC flows on the
PW which for largenumbers of PWs may have scaling implications.
7.4.4. Border Link - LSP stitching
The following figure illustrates the functional interworking among
the networks:
Martinotti, et al. Expires December 9, 2011 [Page 27]
Internet-Draft draft-martinotti-mpls-tp-interworking-02 June 2011
Networks:
Customer Network
+---+ - - - - - - - - - - - - - - - - - -+---+
| ___________ ______________ |
|/IP/MPLS N. \ / MPLS-TP N. \|
+-------------+-----+----------------+
^ \___________/ \______________/
PW emulation
PWs:
|------------SS-PW--------------|
Nodes:
+++++ +++++
+ 1 +----+- - - - - - - - - - - - - - - -+----+ 6 +
+++++ | | +++++
CE +++++ +++++ +++++ +++++ CE
+ 2 +.....+ 3 +-----+ 4 +.......+ 5 +
+++++ +++++ +++++ +++++
LER LER LER LER
PE PE
Border Link - LSP stitching - Networks view
Figure 16
7.4.4.1. OAM considerations
The following figure illustrates the stacking relationship among the
technology layers and OAM relationship among the networks:
Martinotti, et al. Expires December 9, 2011 [Page 28]
Internet-Draft draft-martinotti-mpls-tp-interworking-02 June 2011
Layers:
|--------+-------------CLI---------------+--------|
|--SRV--| |-------------PW--------------| |--SRV--|
|-S-LSP-<->-S-LSP-<->-S-LSP---|
|- SRV -| |--SRV--| |- -SRV- -|
OAM:
(4) >---------------------------< SS-PW
(3) >-------O---------O---------< LSP
(2) >-----< >-----< >-------< TCM
(1) >--< >.....< >-----< >.......< >--< PHY
Nodes:
+++++ +++++ +++++ +++++ +++++ +++++
+ 1 +--+ 2 +.....+ 3 +-----+ 4 +.......+ 5 +--+ 6 +
+++++ +++++ +++++ +++++ +++++ +++++
CE LER LER LER LER CE
Border Link - LSP stitching - Layers and OAM view
Figure 17
Note: in this case a SS-PW extends over the subnetworks as the
stitched LSP does. TCM can be used to monitor the LSP segments.
Several levels of OAM are possible, a subset of them is shown in the
previous figure, however these arenot comprehensive, any subset of
them MAY be configured in a network. A brief description of the
different levels is provided:
(4) Edge-to-Edge MPLS/MPLS-TP OAM on whole network (at PW level)
(3) Edge-to-Edge MPLS/MPLS-TP OAM on whole network (at LSP level)
(2) Edge-to-Edge MPLS OAM, Border MPLS OAM and Edge-toEdge MPLS-TP
OAM on each network partition respectively (at TCM level)
(1) Physical level OAM (MAY be of several kinds)
7.4.4.2. Control Plane considerations
TODO
7.4.4.3. Services view
The generalized service model for all partitioning models is a p2p
connection for the PW client.
Martinotti, et al. Expires December 9, 2011 [Page 29]
Internet-Draft draft-martinotti-mpls-tp-interworking-02 June 2011
7.4.4.4. Resiliency considerations
The LSP can be configured to be protected end to end, have subnetwork
protection or be unprotected at the LSP layer. In the subnetwork
protection scenario the border S-PEs and the borderlink are all
single points of failure.
When GAL/GACh encapsulated OAM is deployed at (a minimum) of the LSP
MEPs, it is possible to envision interworking of the MPLS-TP LSP and
LSPs in the IP/MPLS domain set up with RSVP-TE and/or with LDP. In
the latter case the MPLS-TP LSP maps to a FEC rather than a specific
LSP but the MPLS_TP LSP would need to appear as a FEC in LDP with
associated scaling impacts.
Open Points:
o Edge-to-Edge LSP OAM (3) must be configured on different
subnetworks
o Edge-to-Edge PW OAM (4) must be configured on different
subnetworks
o Interworking between TCM OAM (2) and LSP OAM (3) is still to be
cleared/defined
o Interaction between IP/MPLS and MPLS-TP CPs is still to be
cleared/defined
8. Acknowledgements
The authors gratefully acknowledge the input of Attila Takacs.
9. IANA Considerations
This memo includes no request to IANA.
10. Contributing Authors
David Allan
Ericsson
Holger Way
San Jose
U.S.
Martinotti, et al. Expires December 9, 2011 [Page 30]
Internet-Draft draft-martinotti-mpls-tp-interworking-02 June 2011
Email: david.i.allan@ericsson.com
Elisa Bellagamba
Ericsson
Torshamnsgatan 48
Stockholm 164 80
Sweden
Email: elisa.bellagamba@ericsson.com
Daniele Ceccarelli
Ericsson
Via A. Negrone 1/A
Genova - Sestri Ponente 16153
Italy
Email: daniele.ceccarelli@ericsson.com
David Saccon
Ericsson
Holger Way
San Jose
U.S.
Email: david.saccon@ericsson.com
John Volkering
Ericsson
Email: john.volkering@ericsson.com
Martinotti, et al. Expires December 9, 2011 [Page 31]
Internet-Draft draft-martinotti-mpls-tp-interworking-02 June 2011
11. Security Considerations
This document does not introduce any additional security aspects
beyond those applicable to PWE3 and MPLS.
12. References
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
12.2. Informative References
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.
[RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N.,
and S. Ueno, "Requirements of an MPLS Transport Profile",
RFC 5654, September 2009.
[RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L.
Berger, "A Framework for MPLS in Transport Networks",
RFC 5921, July 2010.
[RFC5860] Vigoureux, M., Ward, D., and M. Betts, "Requirements for
Operations, Administration, and Maintenance (OAM) in MPLS
Transport Networks", RFC 5860, May 2010.
[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.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[ITU-T G.805]
"Generic functional architecture of transport networks",
ID ITU-T G.805, March 2000.
Appendix A. Additional Stuff
This becomes an Appendix.
Martinotti, et al. Expires December 9, 2011 [Page 32]
Internet-Draft draft-martinotti-mpls-tp-interworking-02 June 2011
Authors' Addresses
Riccardo Martinotti
Ericsson
Via A. Negrone 1/A
Genova - Sestri Ponente 16153
Italy
Email: riccardo.martinotti@ericsson.com
Diego Caviglia
Ericsson
Via A. Negrone 1/A
Genova - Sestri Ponente 16153
Italy
Email: diego.caviglia@ericsson.com
Nurit Sprecher
Nokia Siemens Networks
3 Hanagar St. Neve Ne'eman B
Hod Hasharon 45241
Israel
Email: nurit.sprecher@nsn.com
Alessandro D'Alessandro
Telecom Italia
Via Reiss Romoli, 274
Torino 10148
Italy
Email: alessandro.dalessandro@telecomitalia.it
Alessandro Capello
Telecom Italia
Via Reiss Romoli, 274
Torino 10148
Italy
Email: alessandro.capello@telecomitalia.it
Martinotti, et al. Expires December 9, 2011 [Page 33]
Internet-Draft draft-martinotti-mpls-tp-interworking-02 June 2011
Yoshihiko Suemura
NEC Corporation of America
14040 Park Center Road
Herndon, VA 20171
USA
Email: Yoshihiko.Suemura@necam.com
Martinotti, et al. Expires December 9, 2011 [Page 34]