Skip to main content

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.