Liaison statement
LS33 - Liaison Response re MPLS-TP support for MCC and SCC
Additional information about IETF liaison relationships is available on the
IETF webpage
and the
Internet Architecture Board liaison webpage.
State | Posted |
---|---|
Submitted Date | 2009-03-13 |
From Group | ITU-T-SG-15 |
From Contact | Hiroshi Ota |
To Groups | MEAD, mpls |
To Contacts | swallow@cisco.com loa@pi.nu |
Cc | sob@harvard.edu stbryant@cisco.com rcallon@juniper.net dward@cisco.com adrian@olddog.co.uk mpls@lists.ietf.org mpls-interop@ietf.org yoichi.maeda@ntt-at.co.jp sjtrowbridge@alcatel-lucent.com |
Response Contact | tsbsg15@itu.int greg.jones@itu.int hiroshi.ota@itu.int |
Technical Contact | hklam@alcatel-lucent.com |
Purpose | For action |
Deadline | 2009-05-18 Action Taken |
Attachments | LS33 - Liaison Response re MPLS-TP support for MCC and SCC - pdf text |
Body |
Thank you for your liaison titled “MPLS-TP support for MCC and SCC”, dated February 11, 2009. In your liaison, you are asking Q14/15 “to communicate the entire set of specific requirements for transport of MCC and SCC packets on the G-ACh”. Please find a list of requirements below that the G-ACh (draft-ietf-mpls-tp-gach-gal) together with the new Internet-Draft draft-beller-mpls-tp-gach-dcn shall satisfy for building a Management Communication Network (MCN) and a Signalling Communication Network (SCN): 1. A packet encapsulation mechanism must be provided to support the transport of MCN and SCN packets over the G-ACh. 2. The G-ACh carrying the MCN and SCN packets shall support the following application scenarios: a. The G-ACh interconnects two adjacent MPLS-TP nodes (used when the server layer does not provide a Management Communication Channel (MCC) or a Signalling Communication Channel (SCC)). b. The G-ACh is carried by a MPLS-TP tunnel that traverses another operator’s domain (carrier’s carrier scenario) 3. The G-ACh shall provide two independent channels: a MCC to build the MCN and a SCC to build the SCN. The G-ACh packet header shall indicate whether the packet is a MCC or an SCC packet in order to forward it to the management or control plane application for processing. 4. The channel separation mechanism shall allow the use of separate rate limiters and traffic shaping functions for each channel (MCC and SCC) ensuring that the flows do not exceed their assigned traffic profile. The rate limiter and traffic shaper are outside the scope of the MCC and SCC definition. 5. The G-ACh that carries the MCC and SCC shall be capable of carrying different OSI layer 3 (network layer) PDUs. These shall include IPv4, IPv6, and OSI PDUs. The G-ACh header of the MCC/SCC packet shall indicate which layer 3 PDU is contained in the payload field of the packet such that the packet can be forwarded to the related layer 3 process within the management and control plane application, respectively, for further processing. 6. The G-ACh is not required to provide specific security mechanisms. However, the management or control plane protocols that operate over the MCC or SCC are required to provide adequate security mechanisms in order not to be susceptible to security attacks. |