Skip to main content

Liaison statement
Clarification on the intended scope of T-MPLS

Additional information about IETF liaison relationships is available on the IETF webpage and the Internet Architecture Board liaison webpage.
State Posted
Submitted Date 2006-05-04
From Group ITU-T-SG-15
From Contact Hiroshi Ota
To Groups mpls, pwe3
To Contacts George Swallow <swallow@cisco.com>
Loa Andersson <loa@pi.se>
Stewart Bryant <stbryant@cisco.com>
Danny McPherson <danny@arbor.net>
Cc Scott Bradner <sob@harvard.edu>
Yoichi Maeda <maeda@ansl.ntt.co.jp>
sjtrowbridge@lucent.com
ghani.abbas@marconi.com
betts01@nortel.com
Response Contact tsbsg15@itu.int
greg.jones@itu.int
Technical Contact ghani.abbas@marconi.com
betts01@nortel.com
Purpose For information
Attachments Clarification on the intended scope of T-MPLS (see this WinWord file for the diagrams)
Body
Thank you for your informal feedback that has been provided on our previous
liaison statement on T-MPLS Consented Recommendations, we also understand that
you are in the process of developing a formal response.  To assist you in
providing your formal response we would like to provide some additional
clarifications on the intended application of T-MPLS. Our intention in
developing the suite of T-MPLS Recommendations was to define a packet based
transport network technology.  The design objectives of T-MPLS were: a) Follow
the principles of the transport network used in other ITU-T defined transport
technologies (e.g SDH, ATM, OTN). b) To use the PDU and data plane processes
defined by the IETF for MPLS. T-MPLS is not intended to duplicate the
functionality already provided by IP/MPLS. The only client fully described in
the current version of G.8110.1 is point to point Ethernet Virtual Connection
(EVC).  It was agreed to revise the scope of the Recommendation and provide an
appendix II (attached) to reflect this.  Some other key points identified were:
•     The current version of G.8110.1 only defines the bearer plane and only
point to point trails are currently supported.  It should be noted that version
2 of G.8110.1 will add point to multipoint trails. •     Any interworking
with client signals (e.g. MPLS, Ethernet) will be client server i.e. any client
OAM or control protocols will be tunneled transparently across the T-MPLS layer
network. •     Interworking between a client control plane and a (yet to be
defined) T-MPLS control plane will be addressed as a part of the control plane
architecture work. •     The T-MPLS network provides a single hop link to the
client, it is intended to offer a packet switched connection that has similar
operational characteristics to a SDH network providing a PDH link connection,
e.g. these connections must support the ability to activate performance
monitoring and fault management.  Any PM data or failures will be reported to
the transport operations center. We also note your comments on the usage of the
label space terminology.  We will work to clarify and if necessary correct this
in a future revision. We have also agreed to initiate work on the architecture
of a control plane for T-MPLS.  We will use the ASON architecture to provide a
framework to describe the problem that is to be addressed.  This does not imply
that we will specify an ASON control plane.  Once we have refined our
requirements we will communicate them to you for advice on how they may be
addressed.  If the requirements cannot be met by an existing protocol suite we
would like to work with you to develop the appropriate enhancements. We will be
continuing our work on T-MPLS in particular the support of other clients (e.g.
IP/MPLS) at an interim meeting that is planned to be held 19-23 June in Ottawa
Canada.  We will also address any comments that you provide in your planned
liaison statement. Any urgent changes may be included in an amendment or
corrigendum that could be consented in October 2006.  IETF experts are welcome
to participate at this meeting.  Please contact betts01@nortel.com by May 31st
2006 if you should wish to participate.

G.8110.1 draft Appendix II

Support of IP/MPLS LSR based networks by
T-MPLS networks supporting point-to-point EVC services
When two IP/MPLS LSRs are connected via e.g. 802.3 interfaces to a T-MPLS
network, the T-MPLS network can provide an EVC service between these two LSRs
(nodes LSR A and LSR B in Figure II-1) to establish an IP/MPLS link between
these LSRs. The IP/MPLS LSRs encapsulate their IP/MPLS packets into Ethernet
frames with or without VLAN Tag. These Ethernet frames are then transported via
802.3 interfaces to the T-MPLS network edge (nodes X and Y). At the T-MPLS
network edge the Ethernet signal is treated either as an all-to-one EVC service
or as one or more EVC and/or bundled EVC services of which the frames are
mapped into one or more T-MPLS (PW) trails and then transported through the
T-MPLS network. In this network scenario the IP/MPLS routing and control plane
adjacency is between LSR A and LSR B. The T-MPLS network elements do not
participate in the IP/MPLS routing and control plane. A signalling session that
requests PHP is between LSR A and LSR B (T-MPLS nodes X and Y are not involved).

Figure II-1/G.8110.1 – IP/MPLS via EVC over T-MPLS network
The functional model for this scenario is described in Figure II-2. The atomic
functions in the figure are specified in Recommendations G.8021 and G.8121.The
IP/MPLS signals are carried through an IP/MPLS link between LSR A and LSR B
supported by an ETH trail between LSR A and LSR B. The ETH trail is carried
through a serial-compound ETH link supported by an ETY trail interconnecting
LSR A with T-MPLS PE X, a T-MPLS (PW) trail interconnecting T-MPLS PE X with
T-MPLS PE Y and an ETY trail interconnecting T-MPLS PE Y with LSR B.

<<Figure II-2/G.8110.1 – Functional Model for IP/MPLS via EVC over T-MPLS
network>> - see attachment