draft-ietf-ccamp-gmpls-mef-uni-01.txt   draft-ietf-ccamp-gmpls-mef-uni-02.txt 
Internet Draft Lou Berger (LabN) Internet Draft Lou Berger (LabN)
Category: Standards Track Don Fedyk (Nortel) Category: Standards Track Don Fedyk (Nortel)
Expiration Date: February 8, 2009 Expiration Date: August 25, 2009
August 8, 2008 February 25, 2009
Generalized MPLS (GMPLS) Support For Metro Ethernet Forum Generalized MPLS (GMPLS) Support For Metro Ethernet Forum
and G.8011 User-Network Interface (UNI) and G.8011 User-Network Interface (UNI)
draft-ietf-ccamp-gmpls-mef-uni-01.txt draft-ietf-ccamp-gmpls-mef-uni-02.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with 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.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on February 8, 2009. This Internet-Draft will expire on August 25, 2009.
Copyright Notice Copyright and License Notice
Copyright (C) The IETF Trust (2008). Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Abstract Abstract
This document describes a method for controlling two specific types This document describes a method for controlling two specific types
of Ethernet switching via a Generalized Multi-Protocol Label of Ethernet switching via a Generalized Multi-Protocol Label
Switching (GMPLS) based User-Network Interface (UNI). This document Switching (GMPLS) based User-Network Interface (UNI). This document
supports the types of switching required to implied by the Ethernet supports the types of switching required by the Ethernet services
services that have been defined in the context of the Metro Ethernet that have been defined in the context of the Metro Ethernet Forum
Forum (MEF) and International Telecommunication Union (ITU) G.8011. (MEF) and International Telecommunication Union (ITU) G.8011. This
This document is the UNI companion to "Generalized MPLS (GMPLS) document is the UNI companion to "Generalized MPLS (GMPLS) Support
Support For Metro Ethernet Forum and G.8011 Ethernet Service For Metro Ethernet Forum and G.8011 Ethernet Service Switching".
Switching". This document does not define or limit the underlying This document does not define or limit the underlying intra-domain or
intra-domain or Internal NNI (I-NNI) technology used to support the Internal NNI (I-NNI) technology used to support the UNI.
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 8 Acknowledgments ........................................ 10
9 Author's Addresses ........................................ 10 9 Author's Addresses ..................................... 10
10 Full Copyright Statement .................................. 10
11 Intellectual Property ..................................... 11
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
skipping to change at page 4, line 6 skipping to change at page 4, line 6
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 UNI +----------+ +-----------+ UNI Network Network +----------+ +-----------+ Network
+---------+ | | | | +---------+ +---------+ | | | | +---------+
| +----+ | | +-----+ | | +-----+ | | +----+ | | +----+ | | +-----+ | | +-----+ | | +----+ |
------+ | | EPL | | | | | | | | EPL | | +------ ------+ | | EPL | | | | | | | | EPL | | +------
------+ EN +-+-----+--+ CN +---------+ CN +--+-----+-+ EN +------ ------+ EN +-+-----+--+ CN +---------+ CN +--+-----+-+ EN +------
| | | | +--+--| +---+ | | +--+-----+-+ | | | | | | +--+--| +---+ | | +--+-----+-+ | |
| +----+ | | | +--+--+ | | | +--+--+ | | +----+ | | +----+ | | | +--+--+ | | | +--+--+ | | +----+ |
| | | | | | | | | | | | | | | | | | | | | | | |
+---------+ | | | | | | | | +---------+ +---------+ | | | | | | | | +---------+
| | | | | | | | | | | | | | | |
+---------+ | | | | | | | | +---------+ +---------+ | | | | | | | | +---------+
| | | | +--+--+ | | | +--+--+ | | | | | | | +--+--+ | | | +--+--+ | | |
| +----+ | | | | | | +-----+ | | | +----+ | | +----+ | | | | | | +-----+ | | | +----+ |
------+ +-+--+ | | CN +---------+ CN | | | | +------ ------+ +-+--+ | | CN +---------+ CN | | | | +------
------+ EN +-+-----+--+ | | | | +--+-----+-+ EN +------ ------+ EN +-+-----+--+ | | | | +--+-----+-+ EN +------
| | | |EVPL | +-----+ | | +-----+ |EVPL | | | | | | | |EVPL | +-----+ | | +-----+ |EVPL | | | |
| +----+ | | | | | | +----+ | | +----+ | | | | | | +----+ |
| | +----------+ |-----------+ | | | | +----------+ |-----------+ | |
+---------+ Core Network(s) +---------+ +---------+ Core Network(s) +---------+
Ethernet 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
skipping to change at page 5, line 16 skipping to change at page 5, line 16
document is aimed at supporting the MEF UNI Type 3 mode of operation document is aimed at supporting the MEF UNI Type 3 mode of operation
(and not MEF UNI Types 1 and 2). As mentioned above, this document (and not MEF UNI Types 1 and 2). As mentioned above, this document
is limited to covering UNI specific topics. is limited 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 [GMPLS-ESVCS].
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 RSVP objects is not modified by this
document. The relevant procedures in existing documents, notably document. The relevant procedures in existing documents, notably
[GMPLS-ESVCS], [GMPLS-EXT] and [RFC4208], MUST be followed in all [GMPLS-ESVCS], [GMPLS-EXT], [RFC4208] and [RFC4974], MUST be followed
cases not explicitly described in this document. 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 end-point 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
skipping to change at page 8, line 30 skipping to change at page 8, line 30
This Error Code has the following globally-defined Error This Error Code has the following globally-defined Error
Value sub-codes: Value sub-codes:
28* = Unknown Endpoint [This document] 28* = Unknown Endpoint [This document]
(*) Suggested value. (*) Suggested value.
6. Security Considerations 6. Security Considerations
This document introduces new message object formats for use in GMPLS This document makes use of the mechanisms defined in [GMPLS-ESVCS]
signaling [RFC3473]. It does not introduce any new signaling and [RFC4974]. It does not in itself change the security models
messages, nor change the relationship between LSRs that are adjacent offered in each. (Note that the address resolution discussed in
in the control plane. As such, this document introduces no additional Section 2.2 above, parallels the replacement of information that
security considerations. See [RFC3473] for relevant security takes occurs per Section 7.2 of [RFC4974].) See [GMPLS-ESVCS] and
considerations. [RFC4974] for the security considerations that are relevant to and
introduced by the base mechanisms used by this document.
7. References 7. References
7.1. Normative References 7.1. Normative References
[GMPLS-ESVCS] Berger, L., Papadimitriou, P., Fedyk, D., [GMPLS-ESVCS] Berger, L., Papadimitriou, P., Fedyk, D.,
"Generalized MPLS (GMPLS) Support For Metro Ethernet "Generalized MPLS (GMPLS) Support For Metro Ethernet
Forum and G.8011 Ethernet Service Switching", Work in Forum and G.8011 Ethernet Service Switching", Work in
Progress, draft-ietf-ccamp-gmpls-ether-svcs-02.txt, Progress, draft-ietf-ccamp-gmpls-ether-svcs-02.txt,
August 2008. August 2008.
skipping to change at page 9, line 18 skipping to change at page 9, line 18
draft-ietf-ccamp-gmpls-dcsc-channel-ext-00.txt, draft-ietf-ccamp-gmpls-dcsc-channel-ext-00.txt,
Work in Progress, August 2008. Work in Progress, August 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels," RFC 2119. Requirement Levels," RFC 2119.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T.,
Srinivasan, V. and G. Swallow, "RSVP-TE: Extensions Srinivasan, V. and G. Swallow, "RSVP-TE: Extensions
to RSVP for LSP Tunnels", RFC 3209, December 2001. to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3473] Berger, L., Editor, "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling - Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions",
RFC 3473, January 2003.
[RFC4208] Swallow, G., et al. "Generalized Multiprotocol Label [RFC4208] Swallow, G., et al. "Generalized Multiprotocol Label
Switching (GMPLS) User-Network Interface (UNI): Resource Switching (GMPLS) User-Network Interface (UNI): Resource
ReserVation Protocol-Traffic Engineering ReserVation Protocol-Traffic Engineering
(RSVP-TE) Support for the Overlay Model", RFC 4208, (RSVP-TE) Support for the Overlay Model", RFC 4208,
October 2005. October 2005.
[RFC4974] Papadimitriou, D., Farrel, A. "Generalized MPLS [RFC4974] Papadimitriou, D., Farrel, A. "Generalized MPLS
(GMPLS) RSVP-TE Signaling Extensions in support of Calls", (GMPLS) RSVP-TE Signaling Extensions in support of Calls",
RFC 4974, August 2007. RFC 4974, August 2007.
skipping to change at page 10, line 31 skipping to change at line 413
Phone: +1-301-468-9228 Phone: +1-301-468-9228
Email: lberger@labn.net Email: lberger@labn.net
Don Fedyk Don Fedyk
Nortel Networks Nortel Networks
600 Technology Park Drive 600 Technology Park Drive
Billerica, MA, 01821 Billerica, MA, 01821
Phone: +1-978-288-3041 Phone: +1-978-288-3041
Email: dwfedyk@nortel.com Email: dwfedyk@nortel.com
10. Full Copyright Statement Generated on: Wed Feb 25 19:59:59 EST 2009
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
11. Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology
described in this document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights. Information on the procedures with respect to rights
in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required
to implement this standard. Please address the information to the
IETF at ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Generated on: Fri Aug 8 10:17:27 EDT 2008
 End of changes. 17 change blocks. 
52 lines changed or deleted 56 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/