--- 1/draft-ietf-mpls-tp-gach-dcn-04.txt 2009-08-27 15:12:08.000000000 +0200 +++ 2/draft-ietf-mpls-tp-gach-dcn-05.txt 2009-08-27 15:12:08.000000000 +0200 @@ -1,19 +1,19 @@ Networking Working Group D. Beller Internet-Draft Alcatel-Lucent Intended Status: Standards Track A. Farrel -Created: August 14, 2009 Old Dog Consulting -Expires: February 14, 2010 +Created: August 27, 2009 Old Dog Consulting +Expires: February 27, 2010 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 This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. @@ -171,32 +171,32 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MCC/SCC Message | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: G-ACh MCC/SCC Packet o The Channel Type field determines whether the message is an MCC or 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 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 the message SHOULD continue. 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 - 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 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 protocol identifiers to distinguish different protocols [RFC1661], [RFC3818]. 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 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 header. The same procedure is applied when a control plane message is @@ -215,70 +215,82 @@ The DCN channel MUST NOT be used to transport user traffic and SHALL only be used to carry management or control plane messages. Procedures that ensure this (such as deep packet inspection) are outside the scope of this specification. 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 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 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 - entire packet including the MCC/SCC message to the appropriate - processing entity. If the PID value is unknown, the receiver SHALL - silently discard the received packet, MAY increment a counter that - records discarded or errored messages, and MAY log an event. + event. If the PID value is known by the receiver it delivers the + the MCC/SCC message to the appropriate processing entity. If the PID + value is unknown, the receiver SHALL 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 [RFC5586] a receiver MUST NOT 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 stack, it MUST be processed as described in the previous paragraph. 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 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 fast path. The node SHOULD apply layer 3 forwarding procedures - in the slow path and MAY discard or rehect the message using the - layer 3 protocol if it is unable to forward it. + the receiving MPLS-TP node the packet might not be forwarded in the + fast path. A node MAY apply layer 3 forwarding procedures in the slow + path and MAY discard or reject the message using the layer 3 protocol + 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 - 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 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 the PEs. 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 the purpose of exchanging management plane and control plane messages. 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- 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 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 multi-hop delivery of management and control plane messages. 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]) 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 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. + 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 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 over the MCN or SCN are REQUIRED to include adequate security mechanisms and implementations MUST allow operators to configure the use of those mechanisms. 5. IANA Considerations @@ -329,23 +341,26 @@ RFC 1661, July 1994. [RFC3818] Schryver, V., "IANA Considerations for the Point-to-Point Protocol (PPP)", BCP 88, RFC 3818, June 2004. [RFC5036] Andersson, L., Minei, I., and Thomas, B., "LDP Specification", RFC 5036, October 2007. 8. Acknowledgements - The editors wish to thank Pietro Grandi, Martin Vigoureux, and Kam - Lam for their contribution to this document, and the MEAD team for - thorough review. + The editors wish to thank Pietro Grandi, Martin Vigoureux, Kam Lam, + Ben Niven-Jenkins, and Francesco Fondelli for their contribution to + 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 Dieter Beller Alcatel-Lucent Germany EMail: dieter.beller@alcatel-lucent.com Adrian Farrel Old Dog Consulting EMail: adrian@olddog.co.uk