datatracker.ietf.org
Sign in
Version 5.3.0, 2014-04-12
Report a bug

Liaison Statement: LS33 - Liaison Response re MPLS-TP support for MCC and SCC

Submission Date: 2009-03-13
From: ITU-T SG 15 (Greg Jones)
To: IETF MPLS WG Co-Chairs, CC: IETF MEAD team (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.