draft-ietf-mpls-tp-gach-dcn-01.txt   draft-ietf-mpls-tp-gach-dcn-02.txt 
Networking Working Group D. Beller Networking Working Group D. Beller
Internet-Draft Alcatel-Lucent Internet-Draft Alcatel-Lucent
Intended Status: Standards Track A. Farrel Intended Status: Standards Track A. Farrel
Created: May 8, 2009 Old Dog Consulting Created: May 13, 2009 Old Dog Consulting
Expires: November 8, 2009 Expires: November 13, 2009
An Inband Data Communication Network For the MPLS Transport Profile An Inband Data Communication Network For the MPLS Transport Profile
draft-ietf-mpls-tp-gach-dcn-01.txt draft-ietf-mpls-tp-gach-dcn-02.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79. the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 47 skipping to change at page 1, line 47
enable the realization of a control/communication channel associated enable the realization of a control/communication channel associated
with Multiprotocol Label Switching (MPLS) Label Switched Paths with Multiprotocol Label Switching (MPLS) Label Switched Paths
(LSPs), MPLS PWs, MPLS LSP segments, and MPLS sections between (LSPs), MPLS PWs, MPLS LSP segments, and MPLS sections between
adjacent MPLS-capable devices. adjacent MPLS-capable devices.
The MPLS Transport Profile (MPLS-TP) is a profile of the MPLS The MPLS Transport Profile (MPLS-TP) is a profile of the MPLS
architecture that identifies elements of the MPLS toolkit that may be architecture that identifies elements of the MPLS toolkit that may be
combined to build a carrier grade packet transport network based on combined to build a carrier grade packet transport network based on
MPLS packet switching technology. MPLS packet switching technology.
This document describes how the G-ACh may may be used to provide the This document describes how the G-ACh may be used to provide the
infrastructure that forms part of the Management Communication infrastructure that forms part of the Management Communication
Network (MCN) and a Signaling Communication Network (SCN). Network (MCN) and a Signaling Communication Network (SCN).
Collectively, the MCN and SCN may be referred to as the Data Collectively, the MCN and SCN may be referred to as the Data
Communication Network (DCN). The document explains how MCN and SCN Communication Network (DCN). This document explains how MCN and SCN
packets are encapsulated, carried on the G-ACh, and demultiplexed for messages are encapsulated, carried on the G-ACh, and demultiplexed
delivery to the management or signaling/routing components on a label for delivery to the management or signaling/routing control plane
switching router (LSR). components on a label switching router (LSR).
It should be noted that the use of the G-ACh to provide connectivity It should be noted that the use of the G-ACh to provide connectivity
for the DCN is intended for use only where the MPLS-TP network is not for the DCN is intended for use only where the MPLS-TP network is not
capable encapsulating or delivering native DCN messages. capable of encapsulating or delivering native DCN messages.
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
"OPTIONAL" in this document are to be interpreted as described in document are to be interpreted as described in RFC-2119 [RFC2119].
RFC-2119 [RFC2119].
1. Introduction 1. Introduction
The associated channel header (ACH) is specified in [RFC4385]. It is The associated channel header (ACH) is specified in [RFC4385]. It is
a packet header format for use on pseudowire (PW) packets in order to a packet header format for use on pseudowires (PWs) in order to
identify packets used for OAM and similar functions. identify packets used for OAM and similar functions.
The use of the ACH is generalized to apply on any Multiprotocol Label The use of the ACH is generalized in [GAL-GACH] and can be applied on
Switching (MPLS) Label Switching Path (LSP) in [GAL-GACH]. The any Multiprotocol Label Switching (MPLS) Label Switching Path (LSP).
generalized concept is referred to as the Generic Associated Channel This is referred to as the Generic Associated Channel (G-ACh) and is
(G-ACh) and is intended to create a control/communication channel intended to create a control/management communication channel
associated with the LSP that can be used to carry packets used for associated with the LSP that can be used to carry packets used for
OAM and similar functions (e.g., control plane messages). OAM and similar functions (e.g., control/management plane messages).
The purpose of a packet carried on the G-ACh is indicated by the The purpose of a packet carried on the G-ACh is indicated by the
value carried by the Channel Type field of the ACH and a registry of value carried by the Channel Type field of the ACH and a registry of
values is maintained by IANA [RFC4446]. values is maintained by IANA [RFC4446] and [RFC4385]. The combination
of the ACH and the ACH TLVs that may be appended to the ACH is
referred in this document as the G-ACh header.
The MPLS transport profile (MPLS-TP) is described in [MPLS-TP]. The MPLS transport profile (MPLS-TP) is described in [MPLS-TP] and in
MPLS-TP is the application of MPLS to construct a packet transport [TP-REQ]. MPLS-TP is the application of MPLS to construct a packet
network. It constitutes a profile of MPLS that enables operational transport network. It constitutes a profile of MPLS that enables
models typical in transport networks, which includes additional OAM, operational models typical in transport networks, which includes
survivability and other maintenance functions not previously additional OAM, survivability and other maintenance functions not
supported by MPLS. previously supported by MPLS.
Label Switching Routers in MPLS networks may be operated using Label Switching Routers (LSRs) in MPLS networks may be operated using
management protocols or control plane protocols. Messaging in these management protocols or control plane protocols. Messaging in these
protocols is normally achieved using IP packets exchanged over IP- protocols is normally achieved using IP packets exchanged over IP-
capable interfaces. However, some LSRs in MPLS-TP networks may be capable interfaces. However, some LSRs in MPLS-TP networks may be
constructed without support for direct IP encapsulation on their constructed without support for direct IP encapsulation on their
line-side interfaces and without access to an out-of-fiber data line-side interfaces and without access to an out-of-fiber data
communication network. In order that such LSRs can communicate using communication network. In order that such LSRs can communicate using
management plane or control plane protocols channels must be provided management plane or control plane protocols channels must be provided
and the only available mechanism is to use an MPLS label. and the only available mechanism is to use an MPLS label.
The G-ACh provides a suitable mechanism, and this document defines The G-ACh provides a suitable mechanism for this purpose, and this
processes and procedures to allow the G-ACh to be used to build a document defines processes and procedures to allow the G-ACh to be
management communication network (MCN) and a signaling communication used to build a management communication network (MCN) and a
network (SCN) together known as the data communication network (DCN) signaling communication network (SCN) together known as the data
[G.7712]. communication network (DCN) [G.7712].
1.1. Requirements 1.1. Requirements
The requirements presented in this section are based on those The requirements presented in this section are based on those
communicated to the IETF by the ITU-T. communicated to the IETF by the ITU-T.
1. A packet encapsulation mechanism must be provided to support the 1. A packet encapsulation mechanism must be provided to support the
transport of MCN and SCN packets over the G-ACh. transport of MCN and SCN packets over the G-ACh.
2. The G-ACh carrying the MCN and SCN packets shall support the 2. The G-ACh carrying the MCN and SCN packets shall support the
skipping to change at page 4, line 8 skipping to change at page 4, line 8
plane application, respectively, for further processing. plane application, respectively, for further processing.
6. The G-ACh is not required to provide specific security mechanisms. 6. The G-ACh is not required to provide specific security mechanisms.
However, the management or control plane protocols that operate However, the management or control plane protocols that operate
over the MCC or SCC are required to provide adequate security over the MCC or SCC are required to provide adequate security
mechanisms in order not to be susceptible to security attacks. mechanisms in order not to be susceptible to security attacks.
2. Procedures 2. Procedures
Figure 1 depicts the format of an MCC/SCC packet that is sent on the Figure 1 depicts the format of an MCC/SCC packet that is sent on the
G-ACh. To send an MCC/SCC packet on the G-ACh, the MCC/SCC packet is G-ACh. The Channel Type field indicates the function of the ACH
prepended with the ACH and one or more ACH TLVs [GAL-GACH], and MUST message so, to send an MCC/SCC packet on the G-ACh, the MCC/SCC
message is prepended with an ACH with the Channel Type set to
indicate that the message is a MCC or SCC message. The ACH MUST
include the ACH Protocol ID TLV [ACH-TLV] to identify the protocol include the ACH Protocol ID TLV [ACH-TLV] to identify the protocol
type of the MCC or SCC packet. type of the MCC or SCC message, and MAY include further ACH TLVs.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version| Reserved | Channel Type | |0 0 0 1|Version| Reserved | Channel Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACH TLV Header | | ACH TLV Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACH Protocol ID TLV | | ACH Protocol ID TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ zero or more other ACH TLVs ~ ~ zero or more other ACH TLVs ~
~ ~ ~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MCC/SCC Packet | | MCC/SCC Message |
~ ~ ~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: MCC/SCC Packet with Associated Channel Header Figure 1: G-ACh MCC/SCC Packet
o The Channel Type field determines whether the message is an MCC or o The Channel Type field determines whether the message is an MCC or
an SCC message. See Section 4 for the codepoint assignments. an SCC message. See Section 4 for the codepoint assignments.
o The ACH Protocol ID TLV identifies the PDU type of the MCC/SCC o The ACH Protocol ID TLV identifies the PDU type of the MCC/SCC
message. The ACH Protocol ID TLV is defined in [ACH-TLV] and uses message. The ACH Protocol ID TLV is defined in [ACH-TLV] and uses
the PPP protocol identifiers to distinguish different protocols. the PPP protocol identifiers to distinguish different protocols
[RFC1661].
When the G-ACh sender receives an MCC message that is to be sent over When the G-ACh sender receives an MCC message that is to be sent over
the MCC, the sender creates the G-ACh header, provides an ACH the MCC, the sender creates the G-ACh header, provides an ACH
Protocol ID TLV indicating the MCC layer 3 PDU type, sets the Channel Protocol ID TLV indicating the MCC layer 3 PDU type, sets the Channel
Type field to MCC, and prepends the MCC message with the G-ACh Type field to MCC, and prepends the MCC message with the G-ACh
header. The same procedure is applied when a control plane message is header. The same procedure is applied when a control plane message is
to be sent over the SCC. In this case, the sender sets the Channel to be sent over the SCC. In this case, the sender sets the Channel
Type field to SCC. Type field to SCC.
If the MPLS section G-ACh is used, the GAL is added to the packet as If the G-ACh is associated with an MPLS section, the GAL is added to
defined in [GAL-GACH]. The TTL field MUST be set to 1, and the S-bit the message as defined in [GAL-GACH]. The TTL field MUST be set to 1,
of the GAL MUST be set to 1. and the S-bit of the GAL MUST be set to 1.
If the G-ACh is associated with an LSP, the GAL is added to the If the G-ACh is associated with an LSP, the GAL is added to the
packet and the LSP label is pushed on top of the GAL as defined in packet and the LSP label is pushed on top of the GAL as defined in
[GAL-GACH]. The TTL field of the GAL SHOULD be set to 1, and the [GAL-GACH]. The TTL field of the GAL MUST be set to 1, and the S-bit
S-bit of the GAL MUST be set to 1. of the GAL MUST be set to 1.
The DCN channel MUST NOT be used to trnasport user traffic and SHALL The DCN channel MUST NOT be used to transport user traffic and SHALL
only be used to carry management or control plane messages. only be used to carry management or control plane messages.
Procedures that ensure this such as deep packet inspection are Procedures that ensure this such as deep packet inspection are
outside the scope of this specification. outside the scope of this specification.
When a receiver has received a packet on the G-ACh with the ACH When a receiver has received a packet on the G-ACh with the ACH
Channel Type set to MCC or SCC, it SHALL look at the PID field Channel Type set to MCC or SCC, it SHALL look at the PID field
carried in the ACH Protocol ID TLV. If the TLV is absent, the message carried in the ACH Protocol ID TLV. If the TLV is absent, the message
SHALL be silently discarded although a local system MAY increment a SHALL be silently discarded, although a local system MAY increment a
counter or raise an event log. If the PID value is known by the counter that records discarded or errored packets, and MAY log an
receiver it SHALL deliver the entire packet including the MCC/SCC event. If the PID value is known by the receiver it SHALL deliver the
message to the appropriate processing entity. If the PID value is entire packet including the MCC/SCC message to the appropriate
unknown, the receiver SHALL silently discard the received Packet and processing entity. If the PID value is unknown, the receiver SHALL
MAY increment a counter or raise an event log. silently discard the received packet, MAY increment a counter that
records discarded or errored messages, and MAY log an event.
It must be noted that according to [GAL-GACH] a receiver MUST NOT It must be noted that according to [GAL-GACH] a receiver MUST NOT
forward a GAL packet based on the GAL label as is normally the case forward a GAL packet based on the GAL label as is normally the case
for MPLS packets. If the GAL appears at the bottom of the label for MPLS packets. If the GAL appears at the bottom of the label
stack, it MUST be processed as described in the previous paragraph. stack, it MUST be processed as described in the previous paragraph.
Note that there is no requirement for MPLS-TP devices to support IP Note that there is no requirement for MPLS-TP devices to support IP
or OSI forwarding in the fast or slow paths. Thus, if a message is or OSI forwarding in the fast or slow paths. Thus, if a message is
received on the MCC or SCC and is not targeted to an address of the received on the MCC or SCC and is not targeted to an address of the
receiving LSR, the LSR MAY discard the message as incorrectly receiving LSR, the LSR MAY discard the message as incorrectly
received. received using whatever mechanisms are necessary according to layer 3
protocol concerned.
2.1. Pseudowire Setup
Provider Edge nodes may wish to set up PWs using a singaling protocol
that uses remote adjacencies (such as LDP [RFC5036]). In the absence
of an IP-based control plane network, these PEs MUST first set up an
LSP tunnel across the MPLS-TP network. This tunnel can be used both
to carry the PW once it has been set up and to provide a G-ACh based
DCN for control plane communications between t`he PEs.
Note that messages delivered on the G-ACh MUST NOT be forwarded based
on their payload (for example, IP, CLNS, etc).
3. Security Considerations 3. Security Considerations
The G-ACh provides a virtual link between LSRs and might be used to The G-ACh provides a virtual link between LSRs and might be used to
induce many forms of security attack. Protocols that operate over the induce many forms of security attack. Protocols that operate over the
MCN or SCN are REQUIRED to include adequate security mechanisms and MCN or SCN are REQUIRED to include adequate security mechanisms and
implementations MUST allow operators to configure the use of those implementations MUST allow operators to configure the use of those
mechanisms. mechanisms.
4. IANA Considerations 4. IANA Considerations
skipping to change at page 6, line 30 skipping to change at page 6, line 48
[ACH-TLV] Bryant, S., "Definition of ACH TLVs", draft-bryant-xxxx, [ACH-TLV] Bryant, S., "Definition of ACH TLVs", draft-bryant-xxxx,
work in progress. work in progress.
6. Informative References 6. Informative References
[MPLS-TP] Bryant, S., Bocci, M., Lasserre, M., "A Framework for MPLS [MPLS-TP] Bryant, S., Bocci, M., Lasserre, M., "A Framework for MPLS
in Transport Networks", draft-ietf-mpls-tp-framework, work in Transport Networks", draft-ietf-mpls-tp-framework, work
in progress. in progress.
[TP-REQ] B. Niven-Jenkins, Ed., D. Brungard, Ed., M. Betts, Ed.,
N. Sprecher, S. Ueno, "MPLS-TP Requirements",
draft-ietf-mpls-tp-requirements, work in progress.
[G.7712] ITU-T Recommendation G.7712, "Architecture and [G.7712] ITU-T Recommendation G.7712, "Architecture and
specification of data communication network", June 2008. specification of data communication network", June 2008.
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, July 1994.
[RFC5036] Andersson, L., Minei, I., and Thomas, B., "LDP
Specification", RFC 5036, October 2007.
7. Acknowledgements 7. Acknowledgements
The editors wish to thank Pietro Grandi and Martin Vigoureux for The editors wish to thank Pietro Grandi, Martin Vigoureux, and Kam
their contribution to this document. Lam for their contribution to this document.
8. Authors' Addresses 8. Authors' Addresses
Dieter Beller Dieter Beller
Alcatel-Lucent Germany Alcatel-Lucent Germany
EMail: dieter.beller@alcatel-lucent.com EMail: dieter.beller@alcatel-lucent.com
Adrian Farrel Adrian Farrel
Old Dog Consulting Old Dog Consulting
EMail: adrian@olddog.co.uk EMail: adrian@olddog.co.uk
 End of changes. 26 change blocks. 
53 lines changed or deleted 81 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/