draft-ietf-mpls-tp-gach-dcn-03.txt   draft-ietf-mpls-tp-gach-dcn-04.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 28, 2009 Old Dog Consulting Created: August 14, 2009 Old Dog Consulting
Expires: November 28, 2009 Expires: February 14, 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-03.txt draft-ietf-mpls-tp-gach-dcn-04.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 2, line 5 skipping to change at page 2, line 5
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 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). This document explains how MCN and SCN Communication Network (DCN). This document explains how MCN and SCN
messages are encapsulated, carried on the G-ACh, and demultiplexed messages are encapsulated, carried on the G-ACh, and demultiplexed
for delivery to the management or signaling/routing control plane for delivery to the management or signaling/routing control plane
components on a label switching router (LSR). components on an MPLS-TP node.
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 of 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 NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119]. document are to be interpreted as described in 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 pseudowires (PWs) 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 in [GAL-GACH] and can be applied on The use of the ACH is generalized in [RFC5586] and can be applied on
any Multiprotocol Label Switching (MPLS) Label Switching Path (LSP). any Multiprotocol Label Switching (MPLS) Label Switching Path (LSP).
This is referred to as the Generic Associated Channel (G-ACh) and is This is referred to as the Generic Associated Channel (G-ACh) and is
intended to create a control/management 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/management 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] and [RFC4385]. The combination values is maintained by IANA ([RFC4446] and [RFC4385]). The
of the ACH and the ACH TLVs that may be appended to the ACH is combination of the ACH and the ACH TLVs that may be appended to the
referred in this document as the G-ACh header. ACH is referred in this document as the G-ACh header.
The MPLS transport profile (MPLS-TP) is described in [MPLS-TP] and in The MPLS transport profile (MPLS-TP) is described in [MPLS-TP] and in
[TP-REQ]. MPLS-TP is the application of MPLS to construct a packet [TP-REQ]. MPLS-TP is the application of MPLS to construct a packet
transport network. It constitutes a profile of MPLS that enables transport network. It constitutes a profile of MPLS that enables
operational models typical in transport networks, which includes operational models typical in transport networks, which includes
additional OAM, survivability and other maintenance functions not additional OAM, survivability and other maintenance functions not
previously supported by MPLS. previously supported by MPLS.
Label Switching Routers (LSRs) 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 nodes 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 nodes can communicate using
management plane or control plane protocols channels must be provided management plane or control plane protocols, channels must be
and the only available mechanism is to use an MPLS label. provided, and the only available mechanism is to use an MPLS label.
The G-ACh provides a suitable mechanism for this purpose, and this The G-ACh provides a suitable mechanism for this purpose, and this
document defines processes and procedures to allow the G-ACh to be document defines processes and procedures to allow the G-ACh to be
used to build a management communication network (MCN) and a used to build a management communication network (MCN) and a
signaling communication network (SCN) together known as the data signaling communication network (SCN) together known as the data
communication network (DCN) [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
skipping to change at page 3, line 26 skipping to change at page 3, line 26
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
following application scenarios: following application scenarios:
a. The G-ACh interconnects two adjacent MPLS-TP nodes (used when a. The G-ACh interconnects two adjacent MPLS-TP nodes (used when
the server layer does not provide a Management Communication the server layer does not provide a Management Communication
Channel (MCC) or a Signalling Communication Channel (SCC)). Channel (MCC) or a Signalling Communication Channel (SCC)).
b. The G-ACh is carried by a MPLS-TP tunnel that traverses another b. The G-ACh is carried by an MPLS-TP tunnel that traverses
operator's domain (carrier's carrier scenario) another operator's domain (carrier's carrier scenario)
3. The G-ACh shall provide two independent channels: a MCC to build 3. The G-ACh shall provide two independent channels: an MCC to build
the MCN and a SCC to build the SCN. The G-ACh packet header shall the MCN and an 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 indicate whether the packet is an MCC or an SCC packet in order to
forward it to the management or control plane application for forward it to the management or control plane application for
processing. processing.
4. The channel separation mechanism shall allow the use of separate 4. The channel separation mechanism shall allow the use of separate
rate limiters and traffic shaping functions for each channel (MCC rate limiters and traffic shaping functions for each channel (MCC
and SCC) ensuring that the flows do not exceed their assigned and SCC) ensuring that the flows do not exceed their assigned
traffic profile. The rate limiter and traffic shaper are outside traffic profiles. The rate limiters and traffic shapers are
the scope of the MCC and SCC definition. outside the scope of the MCC and SCC definitions.
5. The G-ACh that carries the MCC and SCC shall be capable of 5. The G-ACh that carries the MCC and SCC shall be capable of
carrying different OSI layer 3 (network layer) PDUs. These shall carrying different OSI layer 3 (network layer) PDUs. These shall
include IPv4, IPv6, and OSI PDUs. The G-ACh header of the MCC/SCC 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 packet shall indicate which layer 3 PDU is contained in the
payload field of the packet such that the packet can be forwarded payload field of the packet such that the packet can be delivered
to the related layer 3 process within the management and control to the related layer 3 process within the management and control
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. The Channel Type field indicates the function of the ACH G-ACh. The Channel Type field indicates the function of the ACH
message so, to send an MCC/SCC packet on the G-ACh, the MCC/SCC 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 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 indicate that the message is an 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 message, and MAY include further ACH TLVs. 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 | ~ zero or more ACH TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ zero or more other ACH TLVs ~
~ ~ ~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACH Protocol ID TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 4 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
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 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 MUST be present in a DCN message and MUST be
the PPP protocol identifiers to distinguish different protocols placed last in the sequence of ACh TLVs so that it comes
[RFC1661]. immediately before the MCC/SCC message. Note that this means that
the PID field of the TLV is immediately adjacent to the message
iteslf.
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 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 G-ACh is associated with an MPLS section, the GAL is added to If the G-ACh is associated with an MPLS section, the GAL is added to
the message as defined in [GAL-GACH]. The TTL field MUST be set to 1, the message as defined in [RFC5586]. The TTL field MUST be set to 1,
and the S-bit 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 MUST be set to 1, and the S-bit [RFC5586]. The TTL field of the GAL MUST be set to 1, and the 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 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 SHALL deliver the
entire packet including the MCC/SCC message to the appropriate entire packet including the MCC/SCC message to the appropriate
processing entity. If the PID value is unknown, the receiver SHALL processing entity. If the PID value is unknown, the receiver SHALL
silently discard the received packet, MAY increment a counter that silently discard the received packet, MAY increment a counter that
records discarded or errored messages, and MAY log an event. 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 [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 or slow paths. Thus, if a message is or OSI forwarding in the fast (forwarding) path. Thus, if a message
received on the MCC or SCC and is not targeted to an address of the is received on the MCC or SCC and is not targeted to an address of
receiving LSR, the LSR MAY discard the message as incorrectly the receiving MPLS-TP node, the node MUST NOT forward the packet in
received using whatever mechanisms are necessary according to layer 3 the fast path. The node SHOULD apply layer 3 forwarding procedures
protocol concerned. in the slow path and MAY discard or rehect the message using the
layer 3 protocol if it is unable to forward it.
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 singaling 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 t`he PEs. DCN for control plane communications between the PEs.
Note that messages delivered on the G-ACh MUST NOT be forwarded based 3. Applicability
on their payload (for example, IP, CLNS, etc).
3. Security Considerations The DCN is intented 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.
The G-ACh provides a virtual link between LSRs and might be used to Appendix A of [NM-REQ] describes how Control Channels (CCh) that are
induce many forms of security attack. Protocols that operate over the the links in an MPLS-TP DCN can be out-of-fiber and out-of-band, in-
MCN or SCN are REQUIRED to include adequate security mechanisms and fiber and out-of-band, or in-band with respect to the user data
implementations MUST allow operators to configure the use of those carried by the MPLS-TP network. The Appendix also explains how the
mechanisms. 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.
4. IANA Considerations 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.
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
Channel Types for the Generic Associated Channel are allocated from Channel Types for the Generic Associated Channel are allocated from
the IANA PW Associated Channel Type registry defined in [RFC4446] and the IANA PW Associated Channel Type registry defined in [RFC4446] and
updated by [GAL-GACH]. updated by [RFC5586].
IANA is requested to allocate two further Channel Types as follows: IANA is requested to allocate two further Channel Types as follows:
xx Management Communication Channel (MCC) xx Management Communication Channel (MCC)
yy Signaling Communication Channel (SCC) yy Signaling Communication Channel (SCC)
5. Normative References 6. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4385] Bryant, S., et al., "Pseudowire Emulation Edge-to-Edge [RFC4385] Bryant, S., et al., "Pseudowire Emulation Edge-to-Edge
(PWE3) Control Word for Use over an MPLS PSN", RFC 4385, (PWE3) Control Word for Use over an MPLS PSN", RFC 4385,
February 2006. February 2006.
[RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge
Emulation (PWE3)", RFC 4446, April 2006 . Emulation (PWE3)", RFC 4446, April 2006 .
[GAL-GACH] Vigoureux, M., Bocci, M., Ward, D., Swallow, G., and R. [RFC5586] Bocci, M., Vigoureux, M., and Bryant, S., "MPLS Generic
Aggarwal, "MPLS Generic Associated Channel", Associated Channel", RFC 5586, June 2009.
draft-ietf-mpls-tp-gach-gal, work in progress.
[ACH-TLV] Bryant, S., et al., "Definition of ACH TLV Structure", [ACH-TLV] Bryant, S., et al., "Definition of ACH TLV Structure",
draft-bryant-mpls-tp-ach-tlv, work in progress. draft-bryant-mpls-tp-ach-tlv, work in progress.
6. Informative References 7. 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., [TP-REQ] B. Niven-Jenkins, Ed., D. Brungard, Ed., M. Betts, Ed.,
N. Sprecher, S. Ueno, "MPLS-TP Requirements", N. Sprecher, S. Ueno, "MPLS-TP Requirements",
draft-ietf-mpls-tp-requirements, work in progress. draft-ietf-mpls-tp-requirements, work in progress.
[NM-REQ] Lam, H.-K., Mansfield, S., and Gray, E., "MPLS TP Network
Management Requirements", draft-ietf-mpls-tp-nm-req, 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, [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, July 1994. 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 [RFC5036] Andersson, L., Minei, I., and Thomas, B., "LDP
Specification", RFC 5036, October 2007. Specification", RFC 5036, October 2007.
7. Acknowledgements 8. Acknowledgements
The editors wish to thank Pietro Grandi, Martin Vigoureux, and Kam The editors wish to thank Pietro Grandi, Martin Vigoureux, and Kam
Lam for their contribution to this document. Lam for their contribution to this document, and the MEAD team for
thorough review.
8. 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
Full Copyright Statement Full Copyright Statement
 End of changes. 35 change blocks. 
57 lines changed or deleted 96 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/