draft-ietf-mpls-tp-gach-dcn-04.txt   draft-ietf-mpls-tp-gach-dcn-05.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: August 14, 2009 Old Dog Consulting Created: August 27, 2009 Old Dog Consulting
Expires: February 14, 2010 Expires: February 27, 2010
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-04.txt draft-ietf-mpls-tp-gach-dcn-05.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 4, line 36 skipping to change at page 4, line 36
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MCC/SCC Message | | MCC/SCC Message |
~ ~ ~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: G-ACh MCC/SCC Packet 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 5 for the codepoint assignments. an SCC message. See Section 5 for the codepoint assignments.
o No other ACH TLVs (except the ACH protocol ID TLV - see below) has o No other ACH TLV (except the ACH protocol ID TLV - see below) has
been identified for use on a DCN message. If a message is received been identified for use on a DCN message. If a message is received
carrying an ACH TLV that is not understood in the context of a DCN carrying an ACH TLV that is not understood in the context of a DCN
message, the ACH TLV SHOULD be silently ignored and processing of message, the ACH TLV SHOULD be silently ignored and processing of
the message SHOULD continue. the message SHOULD continue.
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 MUST be present in a DCN message and MUST be message. The ACH MUST be present in a DCN message and MUST be
placed last in the sequence of ACh TLVs so that it comes placed last in the sequence of ACH TLVs so that it comes
immediately before the MCC/SCC message. Note that this means that immediately before the MCC/SCC message. Note that this means that
the PID field of the TLV is immediately adjacent to the message the PID field of the TLV is immediately adjacent to the message
iteslf. itself [ACH-TLV].
The ACH Protocol ID TLV is defined in [ACH-TLV] and uses the PPP The ACH Protocol ID TLV is defined in [ACH-TLV] and uses the PPP
protocol identifiers to distinguish different protocols [RFC1661], protocol identifiers to distinguish different protocols [RFC1661],
[RFC3818]. [RFC3818].
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
skipping to change at page 5, line 32 skipping to change at page 5, line 32
The DCN channel MUST NOT be used to transport 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 that records discarded or errored packets, and MAY log an counter that records discarded or errored packets, and MAY log an
event. If the PID value is known by the receiver it SHALL deliver the event. If the PID value is known by the receiver it delivers the
entire packet including the MCC/SCC message to the appropriate the MCC/SCC message to the appropriate processing entity. If the PID
processing entity. If the PID value is unknown, the receiver SHALL value is unknown, the receiver SHALL silently discard the received
silently discard the received packet, MAY increment a counter that packet, MAY increment a counter that records discarded or errored
records discarded or errored messages, and MAY log an event. messages, and MAY log an event.
It must be noted that according to [RFC5586] a receiver MUST NOT It must be noted that according to [RFC5586] 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 (forwarding) path. Thus, if a message or OSI forwarding in the fast (forwarding) path. Thus, if a message
is received on the MCC or SCC and is not targeted to an address of is received on the MCC or SCC and is not targeted to an address of
the receiving MPLS-TP node, the node MUST NOT forward the packet in the receiving MPLS-TP node the packet might not be forwarded in the
the fast path. The node SHOULD apply layer 3 forwarding procedures fast path. A node MAY apply layer 3 forwarding procedures in the slow
in the slow path and MAY discard or rehect the message using the path and MAY discard or reject the message using the layer 3 protocol
layer 3 protocol if it is unable to forward it. if it is unable to forward it. Thus, protocols making use of the DCN
should make no assumptions about the forwarding capabilities unless
they are determined a priori or through the use of a routing
protocol. Furthermore it is important that user data (i.e., data
traffic) is not routed through the DCN as this would potentially
cause the traffic to be lost or delayed, and might significantly
congest the DCN.
2.1. Pseudowire Setup 2.1. Pseudowire Setup
Provider Edge nodes may wish to set up PWs using a singaling protocol Provider Edge nodes may wish to set up PWs using a signaling protocol
that uses remote adjacencies (such as LDP [RFC5036]). In the absence 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 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 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 to carry the PW once it has been set up and to provide a G-ACh based
DCN for control plane communications between the PEs. DCN for control plane communications between the PEs.
3. Applicability 3. Applicability
The DCN is intented to provide connectivity between management The DCN is intended to provide connectivity between management
stations and network nodes, and between pairs of network nodes, for stations and network nodes, and between pairs of network nodes, for
the purpose of exchanging management plane and control plane the purpose of exchanging management plane and control plane
messages. messages.
Appendix A of [NM-REQ] describes how Control Channels (CCh) that are Appendix A of [NM-REQ] describes how Control Channels (CCh) that are
the links in an MPLS-TP DCN can be out-of-fiber and out-of-band, in- the links in an MPLS-TP DCN can be out-of-fiber and out-of-band, in-
fiber and out-of-band, or in-band with respect to the user data fiber and out-of-band, or in-band with respect to the user data
carried by the MPLS-TP network. The Appendix also explains how the carried by the MPLS-TP network. The Appendix also explains how the
DCN can be constructed from a mix of different types of links and DCN can be constructed from a mix of different types of links and
how routing and forwarding can be used within the DCN to facilitate how routing and forwarding can be used within the DCN to facilitate
multi-hop delivery of management and control plane messages. multi-hop delivery of management and control plane messages.
The G-ACh used as described in this document allows the creation of The G-ACh used as described in this document allows the creation of
a "data channel associated CCh" (type 6 in Appendix A of [NM-REQ]) a "data channel associated CCh" (type 6 in Appendix A of [NM-REQ])
and an "in-band CCh" (type 7 in Appendix A of [NM-REQ]). In the and an "in-band CCh" (type 7 in Appendix A of [NM-REQ]). In the
former case, the G-ACh is associated with an MPLS-TP section. In the former case, the G-ACh is associated with an MPLS-TP section. In the
latter case, the G-ACh is associated with an MPLS-TP LSP or PW and latter case, the G-ACh is associated with an MPLS-TP LSP or PW and
may span one or more hops in the MPLS-TP network. may span one or more hops in the MPLS-TP network.
There is no need to create a CCh for every LSP between a pair of
Indeed, where the nodes are physically adjacent, the G-ACh associated
with the MPLS-TP section would normally be used. Where nodes are
virtually adjacent (that is, connected by LSP tunnels), one or two of
the LSPs might be selected to provide the CCh and a back-up CCh.
4. Security Considerations 4. Security Considerations
The G-ACh provides a virtual link between MPLS-TP nodes and might be The G-ACh provides a virtual link between MPLS-TP nodes and might be
used to induce many forms of security attack. Protocols that operate used to induce many forms of security attack. Protocols that operate
over the MCN or SCN are REQUIRED to include adequate security over the MCN or SCN are REQUIRED to include adequate security
mechanisms and implementations MUST allow operators to configure the mechanisms and implementations MUST allow operators to configure the
use of those mechanisms. use of those mechanisms.
5. IANA Considerations 5. IANA Considerations
skipping to change at page 8, line 7 skipping to change at page 8, line 13
RFC 1661, July 1994. RFC 1661, July 1994.
[RFC3818] Schryver, V., "IANA Considerations for the Point-to-Point [RFC3818] Schryver, V., "IANA Considerations for the Point-to-Point
Protocol (PPP)", BCP 88, RFC 3818, June 2004. Protocol (PPP)", BCP 88, RFC 3818, June 2004.
[RFC5036] Andersson, L., Minei, I., and Thomas, B., "LDP [RFC5036] Andersson, L., Minei, I., and Thomas, B., "LDP
Specification", RFC 5036, October 2007. Specification", RFC 5036, October 2007.
8. Acknowledgements 8. Acknowledgements
The editors wish to thank Pietro Grandi, Martin Vigoureux, and Kam The editors wish to thank Pietro Grandi, Martin Vigoureux, Kam Lam,
Lam for their contribution to this document, and the MEAD team for Ben Niven-Jenkins, and Francesco Fondelli for their contribution to
thorough review. this document, and the MEAD team for thorough review.
Study Group 15 of the ITU-T provided the basis for the requirements
text in Section 1.1.
9. Authors' Addresses 9. 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. 11 change blocks. 
20 lines changed or deleted 35 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/