draft-ietf-ccamp-gmpls-mef-uni-03.txt   rfc6005.txt 
Internet Draft Lou Berger (LabN)
Category: Standards Track Don Fedyk (Alcatel-Lucent)
Expiration Date: April 14, 2010
October 14, 2009 Internet Engineering Task Force (IETF) L. Berger
Request for Comments: 6005 LabN
Generalized MPLS (GMPLS) Support For Metro Ethernet Forum Category: Standards Track D. Fedyk
and G.8011 User-Network Interface (UNI) ISSN: 2070-1721 Alcatel-Lucent
October 2010
draft-ietf-ccamp-gmpls-mef-uni-03.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the Generalized MPLS (GMPLS) Support for Metro Ethernet Forum
provisions of BCP 78 and BCP 79. and G.8011 User Network Interface (UNI)
By submitting this Internet-Draft, each author represents that any Abstract
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document describes a method for controlling two specific types
Task Force (IETF), its areas, and its working groups. Note that of Ethernet switching via a GMPLS-based User Network Interface (UNI).
other groups may also distribute working documents as Internet- This document supports the types of switching required by the
Drafts. Ethernet services that have been defined in the context of the Metro
Ethernet Forum (MEF) and International Telecommunication Union (ITU)
G.8011. This document is the UNI companion to "Generalized MPLS
(GMPLS) Support for Metro Ethernet Forum and G.8011 Ethernet Service
Switching". This document does not define or limit the underlying
intra-domain or Internal NNI (I-NNI) technology used to support the
UNI.
Internet-Drafts are draft documents valid for a maximum of six months Status of This Memo
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This is an Internet Standards Track document.
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at This document is a product of the Internet Engineering Task Force
http://www.ietf.org/shadow.html (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on April 14, 2010. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6005.
Copyright and License Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
This document describes a method for controlling two specific types described in the Simplified BSD License.
of Ethernet switching via a Generalized Multi-Protocol Label
Switching (GMPLS) based User-Network Interface (UNI). This document
supports the types of switching required by the Ethernet services
that have been defined in the context of the Metro Ethernet Forum
(MEF) and International Telecommunication Union (ITU) G.8011. This
document is the UNI companion to "Generalized MPLS (GMPLS) Support
For Metro Ethernet Forum and G.8011 Ethernet Service Switching".
This document does not define or limit the underlying intra-domain or
Internal NNI (I-NNI) technology used to support the UNI.
Table of Contents Table of Contents
1 Introduction ........................................... 3 1. Introduction ....................................................3
1.1 Overview ............................................... 4 1.1. Overview ...................................................4
1.2 Conventions Used In This Document ...................... 5 1.2. Conventions Used in This Document ..........................5
2 Common Signaling Support ............................... 5 2. Common Signaling Support ........................................5
2.1 UNI Addressing ......................................... 5 2.1. UNI Addressing .............................................5
2.2 Ethernet Endpoint (UNI) Identification ................. 6 2.2. Ethernet Endpoint (UNI) Identification .....................6
2.2.1 Address Resolution ..................................... 6 2.2.1. Address Resolution ..................................6
2.3 Connection Identification .............................. 7 2.3. Connection Identification ..................................7
3 EPL Service ............................................ 7 3. EPL Service .....................................................7
4 EVPL Service ........................................... 7 4. EVPL Service ....................................................7
4.1 Egress VLAN ID Control and VLAN ID preservation ........ 7 4.1. Egress VLAN ID Control and VLAN ID Preservation ............7
5 IANA Considerations .................................... 8 5. IANA Considerations .............................................8
5.1 Error Value: Routing Problem/Unknown Endpoint .......... 8 5.1. Error Value: Routing Problem/Unknown Endpoint ..............8
6 Security Considerations ................................ 8 6. Security Considerations .........................................8
7 References ............................................. 8 7. References ......................................................8
7.1 Normative References ................................... 8 7.1. Normative References .......................................8
7.2 Informative References ................................. 9 7.2. Informative References .....................................9
8 Acknowledgments ........................................ 10 Acknowledgments ....................................................9
9 Author's Addresses ..................................... 10
1. Introduction 1. Introduction
[MEF6] and [G.8011] provide parallel frameworks for defining network- [MEF6] and [G.8011] provide parallel frameworks for defining network-
oriented characteristics of Ethernet services in transport networks. oriented characteristics of Ethernet services in transport networks.
The framework discusses general Ethernet connection characteristics, The framework discusses general Ethernet connection characteristics,
Ethernet User-Network Interfaces (UNIs) and Ethernet Network-Network Ethernet User Network Interfaces (UNIs), and Ethernet Network-Network
Interfaces (NNIs). Within this framework, [G.8011.1] defines the Interfaces (NNIs). Within this framework, [G.8011.1] defines the
Ethernet Private Line (EPL) service and [G.8011.2] defines the Ethernet Private Line (EPL) service and [G.8011.2] defines the
Ethernet Virtual Private Line (EVPL) service. [MEF6] covers both Ethernet Virtual Private Line (EVPL) service. [MEF6] covers both
service types. [MEF10.1] defines service parameters and [MEF11] service types. [MEF10.1] defines service parameters and [MEF11]
provides UNI requirements and framework. provides UNI requirements and framework.
This document provides a method for GMPLS based control of LSPs that This document provides a method for GMPLS-based control of Label
support the transport services defined in the above documents at the Switched Paths (LSPs) that support the transport services defined in
UNI network reference points. This document does not define or limit the above documents at the UNI network reference points. This
the underlying intra-domain or Internal NNI (I-NNI) technology used document does not define or limit the underlying intra-domain or
to support the UNI. This document makes use of the GMPLS extensions Internal NNI (I-NNI) technology used to support the UNI. This
defined in [GMPLS-ESVCS] and [GMPLS-EXT]. document makes use of the GMPLS extensions defined in [RFC6004] and
[RFC6002].
The scope of this document covers Ethernet UNI applications, and it The scope of this document covers Ethernet UNI applications, and it
is intended to be consistent with the GMPLS overlay model presented is intended to be consistent with the GMPLS overlay model presented
in [RFC4208] and aligned with GMPLS Core Network signaling. The in [RFC4208] and aligned with GMPLS Core Network signaling. The
scope and reference model used in this document are represented in scope and reference model used in this document are represented in
Figure 1, which is based on Figure 1 of [RFC4208]. Figure 1, which is based on Figure 1 of [RFC4208].
Figure 1 shows two core networks, each containing two core-nodes. Figure 1 shows two core networks, each containing two core nodes.
The core-nodes are labeled 'CN'. Connected to each CN is an edge- The core nodes are labeled 'CN'. Connected to each CN is an edge
node. The edge-nodes are labeled 'EN'. Each EN supports Ethernet node. The edge nodes are labeled 'EN'. Each EN supports Ethernet
Networks and use Ethernet services provided by the core-nodes via a Networks and use Ethernet services provided by the core nodes via a
UNI. Two services are represented; one EPL and one EVPL type UNI. Two services are represented: one EPL and one EVPL type
service. Signaling within the core network is out of scope of this service. Signaling within the core network is out of scope of this
document and may include any technology that supports overlay UNI document and may include any technology that supports overlay UNI
services. The UNI function in the edge-node can be referred to as services. The UNI function in the edge node can be referred to as
the UNI client, or UNI-C, and in the CN as UNI network, or UNI-N. the UNI client, or UNI-C, and in the CN as UNI network, or UNI-N.
Ethernet Ethernet Ethernet Ethernet
Network +----------+ +-----------+ Network Network +----------+ +-----------+ Network
+---------+ | | | | +---------+ +---------+ | | | | +---------+
| +----+ | | +-----+ | | +-----+ | | +----+ | | +----+ | | +-----+ | | +-----+ | | +----+ |
------+ | | EPL | | | | | | | | EPL | | +------ ------+ | | EPL | | | | | | | | EPL | | +------
------+ EN +-+-----+--+ CN +---------+ CN +--+-----+-+ EN +------ ------+ EN +-+-----+--+ CN +---------+ CN +--+-----+-+ EN +------
| | | | +--+--| +---+ | | +--+-----+-+ | | | | | | +--+--| +---+ | | +--+-----+-+ | |
| +----+ | | | +--+--+ | | | +--+--+ | | +----+ | | +----+ | | | +--+--+ | | | +--+--+ | | +----+ |
skipping to change at page 4, line 27 skipping to change at page 4, line 27
| | | | +--+--+ | | | +--+--+ | | | | | | | +--+--+ | | | +--+--+ | | |
| +----+ | | | | | | +-----+ | | | +----+ | | +----+ | | | | | | +-----+ | | | +----+ |
------+ +-+--+ | | CN +---------+ CN | | | | +------ ------+ +-+--+ | | CN +---------+ CN | | | | +------
------+ EN +-+-----+--+ | | | | +--+-----+-+ EN +------ ------+ EN +-+-----+--+ | | | | +--+-----+-+ EN +------
| | | |EVPL | +-----+ | | +-----+ |EVPL | | | | | | | |EVPL | +-----+ | | +-----+ |EVPL | | | |
| +----+ | | | | | | +----+ | | +----+ | | | | | | +----+ |
| | +----------+ |-----------+ | | | | +----------+ |-----------+ | |
+---------+ Core Network(s) +---------+ +---------+ Core Network(s) +---------+
Ethernet UNI UNI Ethernet Ethernet UNI UNI Ethernet
Network <-----> <-----> Network Network <-----> <-----> Network
Scope of this Document Scope of This Document
Legend: EN - Edge Node Legend: EN - Edge Node
CN - Core Node CN - Core Node
Figure 1: Ethernet UNI Reference Model Figure 1: Ethernet UNI Reference Model
1.1. Overview 1.1. Overview
This document uses a common approach to supporting the switching This document uses a common approach to supporting the switching
implied by the Ethernet services defined in [MEF6], [G.8011.1] and implied by the Ethernet services defined in [MEF6], [G.8011.1], and
[G.8011.2]. The approach builds on standard GMPLS mechanisms to [G.8011.2]. The approach builds on standard GMPLS mechanisms to
deliver the required control capabilities. This document reuses the deliver the required control capabilities. This document reuses the
GMPLS mechanisms specified in [GMPLS-ESVCS], [RFC4208], and GMPLS mechanisms specified in [RFC6004], [RFC4208], and [RFC4974].
[RFC4974].
Support for P2P and MP2MP service is required by [G.8011] and Support for Point-to-Point (P2P) and Multipoint-to-Multipoint (MP2MP)
[MEF11]. P2P service delivery support is based on the GMPLS support service is required by [G.8011] and [MEF11]. P2P service delivery
for Ethernet Services covered in [GMPLS-ESVCS]. As with [GMPLS- support is based on the GMPLS support for Ethernet services covered
ESVCS], the definition of support for MP2MP service is left for in [RFC6004]. As with [RFC6004], the definition of support for MP2MP
future study and is not addressed in this document. service is left for future study and is not addressed in this
document.
[MEF11] defines multiple types of control for UNI Ethernet services. [MEF11] defines multiple types of control for UNI Ethernet services.
In MEF UNI Type 1, services are configured manually. In MEF UNI Type In MEF UNI Type 1, services are configured manually. In MEF UNI Type
2, services may be configured manually or via a link management 2, services may be configured manually or via a link management
interface. In MEF UNI Type 3, services may be established and interface. In MEF UNI Type 3, services may be established and
managed via a signaling interface. As with [GMPLS-ESVCS] this managed via a signaling interface. As with [RFC6004], this document
document is aimed at supporting the MEF UNI Type 3 mode of operation is aimed at supporting the MEF UNI Type 3 mode of operation (and not
(and not MEF UNI Types 1 and 2). As mentioned above, this document MEF UNI Types 1 and 2). As mentioned above, this document is limited
is limited to covering UNI specific topics. to covering UNI-specific topics.
Common procedures used to signal Ethernet connections are described Common procedures used to signal Ethernet connections are described
in Section 2 of this document. Procedures related to signaling in Section 2 of this document. Procedures related to signaling
switching in support of EPL services are described in Section 3. switching in support of EPL services are described in Section 3.
Procedures related to signaling switching in support of EVPL services Procedures related to signaling switching in support of EVPL services
are described in Section 4. are described in Section 4.
1.2. Conventions Used In This Document 1.2. 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 [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Common Signaling Support 2. Common Signaling Support
This section describes the common mechanisms for supporting a UNI This section describes the common mechanisms for supporting a UNI
reference point for LSPs that provide the Ethernet Services described reference point for LSPs that provide the Ethernet Services described
in [GMPLS-ESVCS]. in [RFC6004].
Except as specifically modified in this document, the procedures Except as specifically modified in this document, the procedures
related to the processing of RSVP objects is not modified by this related to the processing of Resource ReSerVation Protocol (RSVP)
document. The relevant procedures in existing documents, notably objects is not modified by this document. The relevant procedures in
[GMPLS-ESVCS], [GMPLS-EXT], [RFC4208] and [RFC4974], MUST be followed existing documents, notably [RFC6002], [RFC6004], [RFC4208], and
in all cases not explicitly described in this document. [RFC4974], MUST be followed in all cases not explicitly described in
this document.
2.1. UNI Addressing 2.1. UNI Addressing
LSPs providing Ethernet connections controlled via the mechanisms LSPs providing Ethernet connections controlled via the mechanisms
defined in this document MUST use the addressing and other procedures defined in this document MUST use the addressing and other procedures
defined in [RFC4208]. Of note, this includes the use of the egress defined in [RFC4208]. Of note, this includes the use of the egress
edge-node's IP address in the end-point address field in the SESSION edge node's IP address in the endpoint address field in the SESSION
object. object.
One issue that presents itself with the addressing approach taken in One issue that presents itself with the addressing approach taken in
[RFC4208] is that an ingress edge-node may not receive the egress [RFC4208] is that an ingress edge node may not receive the egress
edge-node's IP address as part of the management, or other, request edge node's IP address as part of the management, or other, request
that results in the initiation of a new Ethernet connection. This that results in the initiation of a new Ethernet connection. This
case is covered as described in Section 7.2 of [RFC4974] and modified case is covered as described in Section 7.2 of [RFC4974] and modified
below in Section 2.2.1. below in Section 2.2.1.
2.2. Ethernet Endpoint (UNI) Identification 2.2. Ethernet Endpoint (UNI) Identification
UNI identification, except as noted below, MUST follow Ethernet UNI identification, except as noted below, MUST follow Ethernet
endpoint (UNI) identification as defined in [GMPLS-ESVCS]. There is endpoint (UNI) identification as defined in [RFC6004]. There is one
one additional case that is covered in this document where the scope additional case that is covered in this document where the scope of
of the Ethernet endpoint identifier is relevant beyond the typical the Ethernet endpoint identifier is relevant beyond the typical case
case of just ingress and egress nodes. of just ingress and egress nodes.
2.2.1. Address Resolution 2.2.1. Address Resolution
At the UNI reference point, it is possible for the ingress edge-node At the UNI reference point, it is possible for the ingress edge node
to not have the egress edge-node's IP address when initiating an LSP. to not have the egress edge node's IP address when initiating an LSP.
This presents an issue as the egress edge-node's IP address is This presents an issue as the egress edge node's IP address is
carried in the SESSION object. This case is handled leveraging the carried in the SESSION object. This case is handled leveraging the
approach described in Section 7.2 of [RFC4974] to address call ID approach described in Section 7.2 of [RFC4974] to address call ID
assignment by the first core-node. assignment by the first core node.
When an edge-node (the UNI-C) initiates an LSP and it has the egress When an edge node (the UNI-C) initiates an LSP and it has the egress
Ethernet endpoint identifier, but does not have its IP address, the Ethernet endpoint identifier, but does not have its IP address, the
edge-node MUST create a Notify message as described in [RFC4974]. edge node MUST create a Notify message as described in [RFC4974].
The Notify message MUST include the CALL_ATTRIBUTES object with the The Notify message MUST include the CALL_ATTRIBUTES object with the
Endpoint ID TLV defined [GMPLS-ESVCS]. The tunnel end point address Endpoint ID TLV defined [RFC6004]. The tunnel endpoint address field
field of the SESSION object in the Notify message MUST be set to zero of the SESSION object in the Notify message MUST be set to zero (0).
(0). The message MUST be addressed and sent to an address associated The message MUST be addressed and sent to an address associated with
with the first core-node. the first core node.
When a core-node, i.e., the node providing the network side of the When a core node, i.e., the node providing the network side of the
UNI (the UNI-N), receives a Notify message with the tunnel end point UNI (the UNI-N), receives a Notify message with the tunnel endpoint
address field of the SESSION object set to zero, it MUST locate the address field of the SESSION object set to zero, it MUST locate the
Endpoint ID TLV in the CALL_ATTRIBUTES object. If the object or TLV Endpoint ID TLV in the CALL_ATTRIBUTES object. If the object or TLV
are not present, the node MUST discard the message. In this case, a are not present, the node MUST discard the message. In this case, a
Message ID Acknowledgment MUST NOT be sent for the Notify message. Message ID Acknowledgment MUST NOT be sent for the Notify message.
When the Endpoint ID TLV is located, the node MUST map the Endpoint When the Endpoint ID TLV is located, the node MUST map the Endpoint
ID into an IP address associated with the egress edge-node. If the ID into an IP address associated with the egress edge node. If the
node is unable to obtain an egress address, it MUST issue an error node is unable to obtain an egress address, it MUST issue an error
response Notify messages according to Section 6.2.2. of [RFC4974]. response Notify messages according to Section 6.2.2. of [RFC4974].
The Error code and value SHOULD be "Routing Problem/Unknown The Error code and value SHOULD be "Routing Problem/Unknown Endpoint"
Endpoint." (To be assigned by IANA). (Error code 24, Error value 35).
When the node is able to obtain an egress address, the end-point When the node is able to obtain an egress address, the endpoint
address field of the SESSION object MUST be set to the obtained address field of the SESSION object MUST be set to the obtained
address, and the Notify message should be sent according to the address, and the Notify message should be sent according to the
standard processing defined in [RFC4974]. The downstream nodes will standard processing defined in [RFC4974]. The downstream nodes will
then process the Notify according to standard processing rules. then process the Notify according to standard processing rules.
When the ingress receives the response Notify message, it SHOULD When the ingress receives the response Notify message, it SHOULD
identify the call based on the Endpoint ID TLV and, when not set to identify the call based on the Endpoint ID TLV and, when not set to
zero on the corresponding setup Notify message, the short and long zero on the corresponding setup Notify message, the short and long
Call IDs. The end-point address field of the SESSION object carried Call IDs. The endpoint address field of the SESSION object carried
in the response Notify message will include the egress' IP address. in the response Notify message will include the egress's IP address.
This returned address MUST be used in all subsequent messages This returned address MUST be used in all subsequent messages
associated with the Ethernet connection. associated with the Ethernet connection.
Note that the procedure described in this section MAY be used when Note that the procedure described in this section MAY be used when
the Call IDs are generated by the initiating UNI or generated by the the Call IDs are generated by the initiating UNI or generated by the
first core-node. first core node.
2.3. Connection Identification 2.3. Connection Identification
With one exception, UNI signaling for Ethernet connections MUST With one exception, UNI signaling for Ethernet connections MUST
follow the Connection Identification procedures defined in [GMPLS- follow the Connection Identification procedures defined in [RFC6004].
ESVCS]. The exception is that the procedures defined in Section 7.2 The exception is that the procedures defined in Section 7.2 of
of [RFC4974] MAY be used to provide support for allocation of Call [RFC4974] MAY be used to provide support for allocation of Call IDs
IDs by the first core-node rather than by the initiating edge-node. by the first core node rather than by the initiating edge node.
3. EPL Service 3. EPL Service
There are no additional UNI specific requirements for signaling LSPs There are no additional UNI-specific requirements for signaling LSPs
supporting Ethernet Private Line (EPL) services. The procedures supporting Ethernet Private Line (EPL) services. The procedures
defined in [GMPLS-ESVCS], as modified above, MUST be followed when defined in [RFC6004], as modified above, MUST be followed when
signaling an LSPs supporting an EPL Service. signaling an LSPs supporting an EPL Service.
4. EVPL Service 4. EVPL Service
There is one additional UNI specific requirements for signaling LSPs There is one additional UNI-specific requirement for signaling LSPs
supporting an EVPL type service. Except as modified above and by supporting an EVPL type service as described in Section 4.1. Except
this section, the procedures defined in [GMPLS-ESVCS] MUST be as modified above and by this section, the procedures defined in
followed when signaling an EVPL Service. [RFC6004] MUST be followed when signaling an EVPL Service.
4.1. Egress VLAN ID Control and VLAN ID preservation 4.1. Egress VLAN ID Control and VLAN ID Preservation
Per [MEF6], the mapping of the single VLAN ID used at the ingress UNI Per [MEF6], the mapping of the single VLAN ID used at the ingress UNI
to a different VLAN ID at the egress UNI is allowed for EVPL services to a different VLAN ID at the egress UNI is allowed for EVPL services
that do not support both bundling and VLAN ID preservation. Such a that do not support both bundling and VLAN ID preservation. Such a
mapping MUST be requested and signaled based on the explicit label mapping MUST be requested and signaled based on the explicit label
control mechanism defined in [RFC4208], and not the mechanisms control mechanism defined in [RFC4208], and not the mechanisms
defined in [GMPLS-ESVCS]. defined in [RFC6004].
As is the case in [GMPLS-ESVCS], when the explicit label control As is the case in [RFC6004], when the explicit label control
mechanism is not used VLAN IDs MUST be preserved, i.e., not modified, mechanism is not used VLAN IDs MUST be preserved, i.e., not modified,
across the LSP. across the LSP.
5. IANA Considerations 5. IANA Considerations
IANA is requested to administer assignment of new values for IANA has assigned new values for namespaces defined in this document
namespaces defined in this document and summarized in this section. and summarized in this section.
5.1. Error Value: Routing Problem/Unknown Endpoint 5.1. Error Value: Routing Problem/Unknown Endpoint
Upon approval of this document, IANA will make the assignment in the IANA has made the following assignment in the "Error Codes and
"Error Codes and Globally-Defined Error Value Sub-Codes" section of Globally-Defined Error Value Sub-Codes" section of the "RSVP
the "RSVP PARAMETERS" registry located at Parameters" registry located at http://www.iana.org:
http://www.iana.org/assignments/rsvp-parameters:
Error Code Meaning Error Code Meaning
24 Routing Problem [RFC3209] 24 Routing Problem [RFC3209]
This Error Code has the following globally-defined Error Under "This Error Code has the following globally-defined Error
Value sub-codes: Value sub-codes:"
28* = Unknown Endpoint [This document]
(*) Suggested value. 35 = Unknown Endpoint [RFC6005]
6. Security Considerations 6. Security Considerations
This document makes use of the mechanisms defined in [GMPLS-ESVCS] This document makes use of the mechanisms defined in [RFC6004] and
and [RFC4974]. It does not in itself change the security models [RFC4974]. It does not in itself change the security models offered
offered in each. (Note that the address resolution discussed in in each. (Note that the address resolution discussed in Section 2.2
Section 2.2 above, parallels the replacement of information that above, parallels the replacement of information that occurs per
takes occurs per Section 7.2 of [RFC4974].) See [GMPLS-ESVCS] and Section 7.2 of [RFC4974].) See [RFC6004] and [RFC4974] for the
[RFC4974] for the security considerations that are relevant to and security considerations that are relevant to and introduced by the
introduced by the base mechanisms used by this document. base mechanisms used by this document.
7. References 7. References
7.1. Normative References 7.1. Normative References
[GMPLS-ESVCS] Berger, L., Fedyk, D., "Generalized MPLS (GMPLS) [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Support Requirement Levels", BCP 14, RFC 2119, March 1997.
For Metro Ethernet Forum and G.8011 Ethernet Service
Switching", Work in Progress,
draft-ietf-ccamp-gmpls-ether-svcs.
[GMPLS-EXT] Berger, L., Fedyk, D., "Generalized MPLS (GMPLS) Data [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
Channel Switching Capable (DCSC) and Channel Set Label and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Extensions", draft-ietf-ccamp-gmpls-dcsc-channel-ext, Tunnels", RFC 3209, December 2001.
Work
in Progress.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter,
Requirement Levels," RFC 2119. "Generalized Multiprotocol Label Switching (GMPLS) User-
Network Interface (UNI): Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE) Support for the Overlay
Model", RFC 4208, October 2005.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., [RFC4974] Papadimitriou, D. and A. Farrel, "Generalized MPLS (GMPLS)
Srinivasan, V. and G. Swallow, "RSVP-TE: Extensions RSVP-TE Signaling Extensions in Support of Calls", RFC
to RSVP for LSP Tunnels", RFC 3209, December 2001. 4974, August 2007.
[RFC4208] Swallow, G., et al. "Generalized Multiprotocol Label [RFC6002] Berger, L. and D. Fedyk, "Generalized MPLS (GMPLS) Data
Switching (GMPLS) User-Network Interface (UNI): Resource Channel Switching Capable (DCSC) and Channel Set Label
ReserVation Protocol-Traffic Engineering Extensions", RFC 6002, October 2010.
(RSVP-TE) Support for the Overlay Model", RFC 4208,
October 2005.
[RFC4974] Papadimitriou, D., Farrel, A. "Generalized MPLS [RFC6004] Berger, L. and D. Fedyk, "Generalized MPLS (GMPLS) Support
(GMPLS) RSVP-TE Signaling Extensions in support of Calls", for Metro Ethernet Forum and G.8011 Ethernet Service
RFC 4974, August 2007. Switching", RFC 6004, October 2010.
7.2. Informative References 7.2. Informative References
[G.8011] ITU-T G.8011/Y.1307, "Ethernet over Transport [G.8011] ITU-T G.8011/Y.1307, "Ethernet over Transport Ethernet
Ethernet services framework", August 2004. services framework", August 2004.
[G.8011.1] ITU-T G.G.8011.1/Y.1307.1, "Ethernet private [G.8011.1] ITU-T G.G.8011.1/Y.1307.1, "Ethernet private line
line service", August 2004. service", August 2004.
[G.8011.2] ITU-T G.8011.2/Y.1307.2, "Ethernet virtual [G.8011.2] ITU-T G.8011.2/Y.1307.2, "Ethernet virtual private line
private line service", September 2005. service", September 2005.
[MEF6] The Metro Ethernet Forum, "Ethernet Services [MEF6] The Metro Ethernet Forum, "Ethernet Services Definitions -
Definitions - Phase I", MEF 6, June 2004 Phase I", MEF 6, June 2004.
[MEF10.1] The Metro Ethernet Forum, "Ethernet Services [MEF10.1] The Metro Ethernet Forum, "Ethernet Services Attributes
Attributes Phase 2", MEF 10.1, November 2006. Phase 2", MEF 10.1, November 2006.
[MEF11] The Metro Ethernet Forum , "User Network [MEF11] The Metro Ethernet Forum , "User Network Interface (UNI)
Interface (UNI) Requirements and Framework", Requirements and Framework", MEF 11, November 2004.
MEF 11, November 2004.
8. Acknowledgments Acknowledgments
Dimitri Papadimitriou provided substantial textual contributions to Dimitri Papadimitriou provided substantial textual contributions to
this document and coauthored earlier versions of this document. this document and coauthored earlier versions of this document.
The authors would like to thank Evelyne Roch and Stephen Shew for The authors would like to thank Evelyne Roch and Stephen Shew for
their valuable comments. their valuable comments.
9. Author's Addresses Authors' Addresses
Lou Berger Lou Berger
LabN Consulting, L.L.C. LabN Consulting, L.L.C.
Phone: +1-301-468-9228 Phone: +1-301-468-9228
Email: lberger@labn.net EMail: lberger@labn.net
Don Fedyk Don Fedyk
Alcatel-Lucent Alcatel-Lucent
Groton, MA, 01450 Groton, MA 01450
Phone: +1-978-467-5645 Phone: +1-978-467-5645
Email: donald.fedyk@alcatel-lucent.com EMail: donald.fedyk@alcatel-lucent.com
Generated on: Wed Oct 14 14:48:05 EDT 2009
 End of changes. 82 change blocks. 
215 lines changed or deleted 197 lines changed or added

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