INTERNATIONAL TELECOMMUNICATION UNION Q12/15 – LS 1 – ETELECOMMUNICATIONSTANDARDIZATION SECTORSTUDY PERIOD 2005-2008

English onlyOriginal: English

Question(s): 12/15 Ottawa, 19-23 June 2006

Source: Q12/15

Title: Response to your liaison providing comments on T-MPLS

LIAISON STATEMENT

To: MFA Forum

Thomas Walsh Email: tdwalsh@lucent.comRao Cherukuri Email: cherukuri@juniper.net

Copy IETF pwe3 and mpls WG

Approval: Agreed to at Q12/15 experts meeting

For: Comment

Deadline: 1st August 2006

Contact: Malcolm BettsNortel NetworksCanada

Tel: +1 613 763 7860Fax: +1 613 763 4371Email: betts01@nortel.com

Thank you for your response to our previous liaison statement. We have the following responses to the issues that you identified. We have attached a revised copy of G.8110.1 that we hope addresses the concerns that you have expressed. If you have any outstanding concerns with this revised document we would appreciate a reply by the deadline indicated above. We have another experts meeting scheduled for September 18-22, in Sophia Antipolis, France, please advise the Rapporteur if any non-ITU members wish to attend this meeting. We will address any comments at this meeting and if necessary make adjustments to the text that we expect to approve at the SG 15 plenary meeting in October 2006.

We will keep you advised of future developments in this area and request your continuing collaboration on this work.

1. Recommendation G.8110.1-LC is based on ITU-T Recommendation G.8110, which describes MPLS layer network architecture. As stated in the G.8110.1-LC summary, the server networks used by the MPLS network are not within the scope of that Recommendation. The summary also states that such architectures are described in other ITU-T Recommendations or IETF RFCs. Without knowing which specific Recommendations or RFCs carry these descriptions, and absent a more detailed description of the requirements, it is difficult to understand what T-MPLS is trying to achieve.

Is T-MPLS intended for use as a wide area network in an NGN or intended for some other specific client or use? What extensions to this set of Recommendations are envisioned?

Attention: Some or all of the material attached to this liaison statement may be subject to ITU copyright. In such a case this will be indicated in the individual document. Such a copyright does not prevent the use of the material for its intended purpose, but it prevents the reproduction of all or part of it in a publication without the authorization of ITU.

- 2 -

A specific “goals and requirements” clause in the Recommendation would be helpful to clarify these issues.

The references to each server layer recommendation are defined in section 7.3/G.8110.1

The T-MPLS requirements are implicit based on the transport network application space. To facilitate our communication with you we will document these implicit assumptions and requirements and send them to you as soon as they are available

2. Can existing MPLS operate alongside T-MPLS or must MPLS be run as a separate layer network independent of T-MPLS?

G.8110.1 defines a connection-oriented network. However, this definition is not a true subset of MPLS and is not compatible with existing MPLS (e.g., there are reserved labels). If this is the intended definition of T-MPLS, then we suggest it should be explicitly stated that T-MPLS and MPLS cannot be mixed. Otherwise, there may be serious interoperability issues if T-MPLS and MPLS are mixed.

If T-MPLS cannot co-exist with MPLS on a link connection with a shared label space then T-MPLS packets must be distinguished from MPLS packets. That is, T-MPLS must not share encapsulation codepoints (e.g., PPP DLL Protocol Numbers, Ethertype, etc.).

In this case, it may add clarity to not call this T-MPLS, but use another name that better distinguishes it from MPLS.

If however, it is intended that T-MPLS can co-exist with MPLS on a link connection with a shared label space, then there are technical issues which must be resolved. In particular, the equipment must allow PHP and OAM (other than Y.1711) and not reserve labels beyond 0-15 across that link connection.

If the intent is to specify a system that is based on MPLS which can co-exist with MPLS, we would welcome opportunity to work with you to align T-MPLS with existing MPLS.

T-MPLS is intended to be a separate layer network with respect to MPLS. However, T-MPLS will use the same data-link protocol ID (e.g. EtherType), frame format and forwarding semantics for as those defined for MPLS frames. T-MPLS and MPLS cannot coexist on the same “interface” (for example they could not coexist on a single Ethernet VLAN, however they could be multiplexed on to a common Ethernet PHY using separate VLANs).

3. The bidirectional LSP definition in clause 6.1 of G.8110.1 is incorrect and should be clarified. The LSPs must have same end points and opposite direction.

Note: In addition, the bidirectional LSP definition depends on the LSP establishment procedures.

The forward and backward directions of a bidirectional LSP must follow the same path (i.e. the same nodes and links). We have implemented some changes to the documents to clarify this.

4. Please clarify how T-MPLS supports connectionless networking. Is it using an overlay network? Are there any special considerations to support IP networks?

T-MPLS is a connection-oriented layer network that provides point to point connections to client layer networks.

5. Please clarify whether the Recommendations considered the requirements of FPBN developed by the ITU-T Focus Group on NGN. Do the T-MPLS Recommendations support those requirements? The FPBN requirements are now in SG13 TD-WP1-0059 and the architecture is in TD 0058.

- 3 -

The FPBN requirements have not been considered in the development of this document. We plan to review these requirements to determine if they are applicable and if so to accommodate them in a future version.

6. Pending specification of the T-MPLS control plane, how are T-MPLS LSPs and PWs established? Are they provisioned? The Recommendations do not say.

The scope of G.8110.1 is to define the transport plane for T-MPLS. The definition of the transport plane is independent of the way that T-MPLS LSPs are setup.

In the absence of a T-MPLS control plane, T-MPLS LSPs are statically provisioned. Our work on a T-MPLS control plane is at a very preliminary stage.

7. Clause 7 of G.8110.1 states that in the TM/client case the adaptation function is associated with “the bottom of the label stack,” and that in the Server/TM case the adaptation function is associated with “the top of the label stack”. However, if a stack has many labels, then the bottom of the stack is not necessarily associated with the T-MPLS client adaptation. The relationship of client and server labels to the label stack should be clarified.

In the current version of the document Ethernet is the only client. Within this limited scope of applications the statements are correct. We are going to revisit the text in the future version when new clients are added.

8. ITU-T Draft Recommendation Y.17fw describes the MPLS OAM Framework. Y.17fw describes several OAM mechanisms for the User Plane. What diagnostic tools are supported in T-MPLS?

T-MPLS specifies Y.1711 OAM in version 1. We intend to work with Q.5/13 to develop diagnostic tools that are required for T-MPLS.

9. MFA Forum draft specification MPLS-ICI currently specifies BFD, LSP-PING and VCCV for OAM. The reasons for this selection are the installed base, support of both fault management and diagnostics. Can you share the reasons for your OAM selection?

The main considerations in selecting Y.1711 OAM were to apply to T-MPLS layer networks the same OAM concepts and paradigm (e.g. connectivity check, alarm suppression, remote defect indication) already available in other transport layer networks (e.g. SDH, OTH) inside the T-MPLS layer itself without requiring IP data plane capabilities. Other Recommendations that may be applicable in this context (e.g. Y.17fw) have not yet been approved.

Attachment: g-8110-1_ar-v2.doc

_____________