Liaison statement
T-MPLS Consented Recommendations

State Posted
Posted Date 2006-04-02
From Group ITU-T-SG-15
From Contact Greg Jones
To Groups MFA-FORUM, mpls
To Contacts George Swallow
Loa Andersson
Response Contact
Technical Contact
Purpose For action
Deadline 2006-04-17 Action Taken
Attachments Consented Text of G.8110.1
Consented Text of G.8112
Consented Text of G.8121
We apologize for not having sent a liaison regarding three consented
Recommendations related to 
T-MPLS. The intent of these Recommendations is not to change MPLS but rather
to identify a 
subset of existing MPLS necessary and sufficient to provide
connection-oriented packet transport.
The approach to the work was to make a profile of the MPLS data plane
functionalities defined in 
IETF RFCs using the description of MPLS provided in G.8110 (which was approved
last year).  
The intended application of this profile is to provide a connection-oriented
packet transport 
The focus of the three new recommendations is on the data plane aspects of
T-MPLS. Control plane 
aspects are currently for further study and the work on this subject is
According to our work methodology the T-MPLS definitions are split into the
three main 
Recommendations that have been consented in February 2006:
*	G.8110.1 dealing with the T-MPLS Architecture
*	G.8112 dealing with T-MPLS interface specification
*	G.8121 dealing with T-MPLS equipment functional specification
A brief high-level introduction of the essential features and selected options
for Transport MPLS 
can be found in section 6/G.8110.1.
The objective of the work done by ITU-T SG15 was to define a way to use MPLS
as a connection-
oriented packet-based transport solution for packet aware transport networks
that can support both 
packet and circuit (e.g. SDH, OTH or WDM) switching technologies under a
common operation, 
control and management paradigm. For this purpose T-MPLS deploys the MPLS
frame format, 
Client to MPLS mapping and MPLS to MPLS multiplexing and complements this with
network OAM (Y.1711), nested connection monitoring requiring the labels to be
present up to the 
final node in the network, protection switching (Y.1720/G.8131), transport
network based control 
and management planes, maintaining frame ordering and a restricted number of
classes of 
*	MPLS has many applications and it is desirable to identify a subset of MPLS
technology that 
provides the necessary and sufficient functionality for transport
We have indicated below some of the options we have selected :-
*	In IETF RFCs the usage of PHP is optional. We decided not to use it in order
to simplify OAM 
*	In IETF RFCs the usage of merging is optional. We decided not to use it in
order to simplify 
OAM procedures and also because the relative lower number of LSPs to be
supported is not 
considered a major scaling issue
*	The usage of ECMP is optional. We decided not to use it in order to simplify
OAM procedures
*	Leaving labels 16-31 for further study was seen as a no change because the
label allocation on a 
link is defined in IETF RFCs as a local matter for any MPLS device.
We are not expecting that the current version of the specification is going to
create any 
interoperability issue. We envisage two possible cases of interoperability:
1.	Interoperability between a T-MPLS box and an existing full-featured and
fully configurable 
MPLS box can be solved by configuring the MPLS box to use the same options
selected by T-
MPLS (T-MPLS being a profile of MPLS this should be possible). In this case
the link between 
the two boxes is a T-MPLS link and in the scope of our Recommendations.
2.	Interoperability between a transport platform supporting T-MPLS and an
existing MPLS box 
that uses a different option selection than T-MPLS, should be solved by the
transport platform. 
In this case the link between the transport platform and the MPLS box is not a
T-MPLS link and 
therefore it is outside the scope of T-MPLS recommendations. We are looking
for cooperation 
with IETF to develop the detailed specification of this case.
Please find attached the text of the consented Recommendations.  Please note
that some minor 
modifications may be made to these draft Recommendations as a result of
comments made during 
the approval process
We will appreciate your comments and suggestions in relation to the initial
scope of T-MPLS as a 
packet transport network technology.
We are planning to review your comments during the next meeting that is
planned in Kobe (Japan) 
on 22-27 April 2006. Results of the comments will be included into our future
work (e.g. corrigenda 
or amendments) on T-MPLS Recommendations. Amendments of T-MPLS Recommendations
already in our plan for the next SG15 plenary meeting in November 2006.We are
looking forward 
for future cooperation with you in T-MPLS data plane and control plane

Attachments: Consented Text of G.8110.1, G.8112, G.8121