draft-ietf-ccamp-ethernet-gmpls-provider-reqs-00.txt   draft-ietf-ccamp-ethernet-gmpls-provider-reqs-01.txt 
Network working Group W. Imajuku (ed.) NTT Network Working Group W. Imajuku, Ed., NTT
Internet-Draft T. Otani (ed.) KDDI R&D Labs. Internet-Draft Otani, Ed., KDDI
Category: Informational N. Bitar (ed.) Verizon Intended status: Informational N. Bitar, Ed., Verizon
Expires December 2008 June 11 2008 Expires: June 13, 2009
December 10, 2008
Service Provider Requirements for Ethernet control with GMPLS Service Provider Requirements for Ethernet control with GMPLS
draft-ietf-ccamp-ethernet-gmpls-provider-reqs-00.txt draft-ietf-ccamp-ethernet-gmpls-provider-reqs-01.txt
Status of this Memo Status of this Memo
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 Section 6 of 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
skipping to change at page 1, line 34 skipping to change at page 1, line 35
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/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
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 December 10, 2008. This Internet-Draft will expire on June 13, 2009.
Abstract Abstract
Generalized Multi-Protocol Label Switching (GMPLS) is applicable to Generalized Multi-Protocol Label Switching (GMPLS) is applicable to
Ethernet switches supporting Provider Backbone Bridge Traffic Ethernet switches supporting Provider Backbone Bridge Traffic
Engineering (PBB-TE) networks. The GMPLS controlled Ethernet label Engineering (PBB-TE) networks. The GMPLS controlled Ethernet label
switch network not only automates creation of Ethernet Label Switched switch network not only automates creation of Ethernet Label Switched
Paths(Eth-LSPs), it also provides sophisticated Eth-LSP recovery Paths(Eth-LSPs), it also provides sophisticated Eth-LSP recovery
Mechanisms such as protection and restoration of an Eth-LSP. This Mechanisms such as protection and restoration of an Eth-LSP. This
document describes the requirements for the set of solutions of GMPLS document describes the requirements for the set of solutions of GMPLS
controlled Ethernet label switch networks. controlled Ethernet label switch networks.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 4
3. Reference model . . . . . . . . . . . . . . . . . . . . . . . 3 3. Reference model . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Single-layer network . . . . . . . . . . . . . . . . . . . 3 3.1. Single Layer . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Multi-layer network . . . . . . . . . . . . . . . . . . . 4 3.2. Multi Layer . . . . . . . . . . . . . . . . . . . . . . . 5
4. Requirements for Ethernet layer control . . . . . . . . . . . 5 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Control plane architecture and functionality . . . . . . 5 4.1. Control plane architecture and functionality . . . . . . . 7
4.1.1. In-band control plane channel . . . . . . . . . . . . . . 5 4.1.1. In-band control channel . . . . . . . . . . . . . . . 7
4.1.2 Neighbor discovery mechanism . . . . . . . . . . . . . . 5 4.1.2. Neighbor discovery mechanism . . . . . . . . . . . . . 7
4.2. Ethernet LSP control . . . . . . . . . . . . . . . . . . 5 4.1.3. Addressing . . . . . . . . . . . . . . . . . . . . . . 7
4.2.1. Prevention of Loops . . . . . . . . . . . . . . . . . . . 5 4.2. Ethernet LSP control . . . . . . . . . . . . . . . . . . . 7
4.2.2. Service Control . . . . . . . . . . . . . . . . . . . . . 6 4.2.1. Prevention of Loops . . . . . . . . . . . . . . . . . 7
4.2.3 P2MP and MP2MP LSP . . . . . . . . . . . . . . . . . . . 6 4.2.2. Service control . . . . . . . . . . . . . . . . . . . 7
4.3. OA&M related functionality . . . . . . . . . . . . . . . 6 4.2.3. P2MP and MP2MP requirements . . . . . . . . . . . . . 8
4.4. Protection and restoration Related functionalities . . . 6 4.2.4. Asymmetric bandwidth . . . . . . . . . . . . . . . . . 8
4.5. Link Aggregation Group related functionalities . . . . . 6 4.2.5. QoS control . . . . . . . . . . . . . . . . . . . . . 8
4.5.1 Failure or deletion of LAG member link . . . . . . . . . 7 4.3. OA&M related functionality . . . . . . . . . . . . . . . . 8
4.5.2 Recovery or addition of LAG member link . . . . . . . . . 7 4.4. Protection and Restoration related functionality . . . . . 8
4.6. Inter-domain Ethernet LSP . . . . . . . . . . . . . . . . 7 4.5. Link Aggregation Group (LAG) related functionality . . . . 9
4.7. Multi-layer network . . . . . . . . . . . . . . . . . . . 7 4.5.1. Failure or deletion of LAG member link . . . . . . . . 9
4.7.1. Dynamic formation of LAG . . . . . . . . . . . . . . . . 7 4.5.2. Recovery or addition of LAG member link . . . . . . . 9
4.7.2. Other requirements . . . . . . . . . . . . . . . . . . . 7 4.6. Inter-domain Ethernet LSP . . . . . . . . . . . . . . . . 9
4.8 Scalability . . . . . . . . . . . . . . . . . . . . . . . 8 4.7. Multi-layer network . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 4.7.1. Dynamic formation of LAG . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 4.7.2. Other requirements . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.8. Scalability . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative references . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7.2. Informative references . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15
Copyright Statement. . . . . . . . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 19
1. Introduction 1. Introduction
Scalability and manageability of Ethernet switch networks has Scalability and manageability of Ethernet switch networks has
continuously improved, and the deployment of Ethernet switches continuously improved, and the deployment of Ethernet switches
supporting Provider Bridging (PB) [IEEE802.1ad] has became one of the supporting Provider Bridging (PB) [IEEE802.1ad] has became one of the
solutions for service providers to provide enterprise WAN/LAN services. solutions for service providers to provide enterprise WAN/LAN
IEEE standardization activities of Provider Backbone Bridge(PBB) services. IEEE standardization activities of Provider Backbone
[IEEE 802.1ah] and PBB for Traffic Engineering (PBB-TE) [IEEE802.1Qay] Bridge(PBB) [IEEE802.1ah] and PBB for Traffic Engineering (PBB-TE)
provide an opportunity not only for enhancing the scalability, [IEEE802.1Qay] provide an opportunity not only for enhancing the
manageability, and controllability of the Ethernet service networks, scalability, manageability, and controllability of the Ethernet
but also for more efficiently deploying access/metro access networks. service networks, but also for more efficiently deploying access/
metro access networks.
Generalized Multi-Protocol Label Switching (GMPLS) provides the Generalized Multi-Protocol Label Switching (GMPLS) provides the
framework for handling and controlling various types of switching framework for handling and controlling various types of switching
technologies, namely packet switching with various label formats TDM technologies, namely packet switching with various label formats TDM
switching, and wavelength switching [RFC3945]. Therefore, the combined switching, and wavelength switching [RFC3945]. Therefore, the
use of GMPLS and PBB-TE is a fairly suitable "use case" that combined use of GMPLS and PBB-TE is a fairly suitable "use case" that
contributes to enhancing the flexibility of Ethernet Label Switched contributes to enhancing the flexibility of Ethernet Label Switched
Path (Eth-LSP) over Ethernet switch networks without defining Path (Eth-LSP) over Ethernet switch networks without defining
additional connection layers. additional connection layers.
This document describes requirements for GMPLS protocols to control This document describes requirements for GMPLS protocols to control
Ethernet label switch networks and comprises mainly two parts. Ethernet label switch networks and comprises mainly two parts. The
The first one is the requirements for GMPLS extension for first one is the requirements for GMPLS extension for controlling
controlling Ethernet layer. The second one includes the requirements Ethernet layer. The second one includes the requirements for GMPLS
for GMPLS extensions to support multi-layer operation. Although a extensions to support multi-layer operation. Although a large
large portion of requirements in the second scope coincides with the portion of requirements in the second scope coincides with the
description in [Interwk-fwk] and [Interwk-req], some of important description in [RFC5145] and [RFC5146], some of important
requirements are also described in this document. requirements are also described in this document.
2. Conventions used in this document 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 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
this document are to be interpreted as described in RFC 2119 document are to be interpreted as described in [RFC2119].
[RFC2119].
3. Reference model 3. Reference model
3.1 Single Layer 3.1. Single Layer
This document describes requirements based on the reference model This document describes requirements based on the reference model
depicted in Fig. 1. The first reference model is an intra-domain depicted in Fig.1. The first reference model is an intra-domain and
and single layer GMPLS controlled Ethernet label switching network single layer GMPLS controlled Ethernet label switching network in
in which Eth-LSPs traverse over between Back Bone Core Bridges which Eth-LSPs traverse over between Back Bone Core Bridges (BCBs) or
(BCBs) or Back Bone Edge Bridges (BEBs). Back Bone Edge Bridges (BEBs).
-------- --------
| LSR3 |__ P-based IF | LSR3 |__ P-based IF
-------- ----- _____|(IB-BEB)|__ S-tagged IF -------- ----- _____|(IB-BEB)|__ S-tagged IF
P-based IF | LSR1 |____|LSR2 | | |__ I-tagged IF P-based IF | LSR1 |____|LSR2 | | |__ I-tagged IF
S-tagged IF |(IB-BEB)| |(BCB)| -------- S-tagged IF |(IB-BEB)| |(BCB)| --------
I-tagged IF | | | |_____ -------- I-tagged IF | | | |_____ --------
-------- ----- | LSR4 | -------- ----- | LSR4 |
| (B-BEB)| | (B-BEB)|
| |__ I-tagged IF | |__ I-tagged IF
-------- --------
skipping to change at page 3, line 52 skipping to change at page 5, line 28
P-based IF | LSR1 |____|LSR2 | | |__ I-tagged IF P-based IF | LSR1 |____|LSR2 | | |__ I-tagged IF
S-tagged IF |(IB-BEB)| |(BCB)| -------- S-tagged IF |(IB-BEB)| |(BCB)| --------
I-tagged IF | | | |_____ -------- I-tagged IF | | | |_____ --------
-------- ----- | LSR4 | -------- ----- | LSR4 |
| (B-BEB)| | (B-BEB)|
| |__ I-tagged IF | |__ I-tagged IF
-------- --------
| GMPLS Eth-LSP | | GMPLS Eth-LSP |
| (BVID/BMAC) | | (BVID/BMAC) |
|<---------------| |<---------------|
Figure 1 Single layer GMPLS controlled PBB-TE network Figure 1 Single layer GMPLS controlled PBB-TE network
The BEBs provide mainly three types of service interfaces, namely The BEBs provide mainly three types of service interfaces, namely
Port based service interface (P-based IF), S-tagged service interface Port based service interface (P-based IF), S-tagged service interface
(S-tagged IF), and I-tagged service Interface (I-tagged IF) (S-tagged IF), and I-tagged service Interface (I-tagged IF)
[IEEE802.1ah]. The "P-based IF" and "S-tagged IF" are connected to the [IEEE802.1ah]. The "P-based IF" and "S-tagged IF" are connected to
I-component of a BEB (I-BEB), while the I-tagged IF is connected to the I-component of a BEB (I-BEB), while the I-tagged IF is connected
the B-component of a BEB (B-BEB). "S-tagged IF" can perform various to the B-component of a BEB (B-BEB). "S-tagged IF" can perform
types of mapping between Service VLAN ID (S-VID) and Backbone various types of mapping between Service VLAN ID (S-VID) and Backbone
instance Service Identifier (I-SID). Here, S-VID is assigned within instance Service Identifier (I-SID). Here, S-VID is assigned within
customer network domain or Provider Bridge (PB) domain. On the other customer network domain or Provider Bridge (PB) domain. On the other
hand, I-SID is defined between I-components of BEBs. hand, I-SID is defined between I-components of BEBs.
3.2 Multi-layer 3.2. Multi Layer
The second reference model is Ethernet and L1 (such as TDM, OTN, The second reference model is Ethernet and L1 (such as TDM, OTN, etc)
etc) multi-layer network. Each Ethernet switch node behaves as multi-layer network. Each Ethernet switch node behaves as a border
a border node between the Ethernet layer and optical Layers. node between the Ethernet layer and optical Layers. Each BCB or BEB
Each BCB or BEB terminates Optical Label Switched Path (O-LSPs) terminates Optical Label Switched Path (O-LSPs) with Ethernet
with Ethernet encoding type and some O-LSPs dynamically form LAG. encoding type and some O-LSPs dynamically form LAG. Thus, some Eth-
Thus, some Eth-LSPs traverse over multiple O-LSPs, while other LSPs traverse over multiple O-LSPs, while other Eth-LSPs traverse
Eth-LSPs traverse over single O-LSPs. over single O-LSPs.
Also, it is technically possible to form multiple layer Ethernet Also, it is technically possible to form multiple layer Ethernet
switch networks. Namely, the reference model is defined as the case switch networks. Namely, the reference model is defined as the case
that Ethernet switch network substitutes L1 network in Fig.2, and that Ethernet switch network substitutes L1 network in Fig.2, and
realizes MAC in MAC Ethernet transport. realizes MAC in MAC Ethernet transport. The routing information of
The routing information of optical layer may be isolated (overlay optical layer may be isolated (overlay model), shuffled (peer model),
model), shuffled (peer model), or virtualized with FA-LSPs or virtualized with FA-LSPs (augmented model) for Ethernet switch
(augmented model) for Ethernet switch layer. layer.
-------- ------ -------- -------- ------ --------
P-based IF __| LSR1 | | LSR2 | | LSR3 |__ P-based IF P-based IF __| LSR1 | | LSR2 | | LSR3 |__ P-based IF
S-tagged IF __|(IB-BEB)| | (BCB)| |(IB-BEB)|__ S-tagged IF S-tagged IF __|(IB-BEB)| | (BCB)| |(IB-BEB)|__ S-tagged IF
I-tagged IF __| | | | | |__ I-tagged IF I-tagged IF __| | | | | |__ I-tagged IF
-------- ------ -------- -------- ------ --------
| | ||LAG LAG|| | | ||LAG LAG||
......................|...........|..||..........||................... ..................|...........|..||..........||...................
| | || || | | || ||
---+---- ------ ------ ---+---- ------ ------
| LSR A |_____|LSR B |_____|LSR C | | LSR A |_____|LSR B |_____|LSR C |
| (LSC) | |(LSC) | WDM |(LSC) | | (LSC) | |(LSC) | WDM |(LSC) |
-------- ------ ------ -------- ------ ------
| GMPLS Eth-LSP (BVID/BMAC)| | GMPLS Eth-LSP (BVID/BMAC)|
|<------------------------>| |<------------------------>|
| O-LSP | | O-LSP | | O-LSP | | O-LSP |
|<--------->| |<-------->| |<--------->| |<-------->|
Figure 2 Multi-layer GMPLS controlled Ethernet label switched network Figure 2 Multi-layer GMPLS controlled Ethernet label switched network
4. Requirements 4. Requirements
Section 4.1 to 4.6 describe requirements for single layer Ethernet 4.1. Control plane architecture and functionality
label swicth network based on the reference model from Fig.1.
In addition, section 4.7 describes requirements for multiple
layer network with Ethernet layer and circuit switch layer (such as
wavelength switched layer and so on). Finally, section 4.8 describes
generic requirements applicable to single and multiple layer
networks.
4.1 Control plane architecture and functionality
4.1.1 In-band control plane channel 4.1.1. In-band control channel
The solution should be able to establish in-band control channel, The solution should be able to establish in-band control channel,
while preserving the solution of out-band control channel. while preserving the solution of out-band control channel. The
The solution should include negotiation mechanism to specify bandwidth solution should include negotiation mechanism to specify bandwidth
and priority of control-channel between peer Ethernet switches. and priority of control-channel between peer Ethernet switches.
4.1.2 Neighbor discovery mechanism 4.1.2. Neighbor discovery mechanism
The solution MUST be able to realize automatic neighbor discovery The solution MUST be able to realize automatic neighbor discover as
as realized in current PB or PBB networks. realized in current PB or PBB networks. Namely, the solution MUST
Namely, the solution MUST support an automatic negotiation mechanism support an automatic negotiation mechanism to exchange information of
to exchange information of Node ID, TE-Link ID, Data-link ID Node ID, TE-Link ID, Data-link ID (in the case of link Bundling), and
(in the case of link Bundling), and IP address of the control channel. IP address of the control channel. On the other hand, the extension
On the other hand, the extension should be minimized by making use should be minimized by making use of [IEEE802.1AB].
of [IEEE 802.1AB].
4.2 Ethernet LSP control 4.1.3. Addressing
4.2.1 Prevention of Loops TBD
4.2. Ethernet LSP control
4.2.1. Prevention of Loops
The solution should have reliability to prevent creating loops of The solution should have reliability to prevent creating loops of
Eth-LSPs. Specifically if the solution supports numbered TE-Link Eth-LSPs. Specifically if the solution supports numbered TE-Link
addressing, the solution should define a methodology and protocol addressing, the solution should define a methodology and protocol
extensions if needed to detect or prevent loops. extensions if needed to detect or prevent loops.
4.2.2 Service control 4.2.2. Service control
The solution should control various types of service interfaces The solution should control various types of service interfaces
defined in [IEEE802.1ah]. The service types of Egress port defined in [IEEE802.1ah]. The service types of Egress port
1) Port based service interface 1) Port based service interface
2) S-tagged service interface 2) S-tagged service interface
a) one-to-one mapping of S-VIDs to I-SIDs a) one-to-one mapping of S-VIDs to I-SIDs
b) bundled mapping of S-VIDs to I-SIDs
such as many-to-one, all-to-one, transparent mapping b) bundled mapping of S-VIDs to I-SIDs such as many-to-one, all-to-
3) I-tagged service interface one, transparent mapping
should be controllable in addition to assignment of Egress port
itself.
Also, the solution should be flexible to following operational Also, the solution should be flexible to following operational
scenarios, scenarios,
1) Any change of mapping of S-VIDs to I-SIDs 1) Any change of mapping of S-VIDs to I-SIDs
2) Flexibility to nest or stitch higher layer Eth-LSPs. 2) Flexibility to nest or stitch higher layer Eth-LSPs.
3) Any change of bandwidth of Eth-LSPs. Here, the solution
of bandwidth modification scenario may include bundling
of multiple Eth-LSPs.
4.2.3 P2MP and MP2MP requirements 3) Any change of bandwidth of Eth-LSPs. Here, the solution of
bandwidth modification scenario may include bundling of multiple Eth-
LSPs.
Detail requirements will be described in future version. 4.2.3. P2MP and MP2MP requirements
4.3 OA&M related functionality To provide the service such as a content distribution, the creation
of uni-directional P2MP Eth-LSPs should be supported. Also, to
provide E-tree type services with multicast traffic, the creation of
bi-directional P2MP/MP2P Eth-LSPs should be supported. The MP2MP
requirement is under discussion.
OAM mechanisms must be defined for GMPLS controlled E-LSPs. 4.2.4. Asymmetric bandwidth
Since the data plane is still Ethernet based, the mechanisms
should capitalize on existing IEEE802.1ad and Y.1731 mechanisms.
Also, the solution should provide admin status control mechanism To provide the service which has asymmetric traffic pattern such as a
to coordinate with Connectivity Fault Management (CFM) kind of E-tree type services, the creation of asymmetric bandwidth
functionality [IEEE802.1ag]. bi-directional Eth-LSPs should be supported. The bandwidth
modification of Eth-LSPs in operation should be also supported.
4.4 Protection and Restoration related functionality 4.2.5. QoS control
Detail requirements will be described in future version. The routing and signaling extensions to control QoS based on Ethernet
traffic parameters defined in [MEF10.1] should be supported. Unused
bandwidth per CoS should be exhanged by routing extensions like
[RFC4124] and the CoS and bandwidth profile such as CIR, CBS, EIR and
EBS for a requested LSP should be carried by signaling extensions for
bandwidth accounting and traffic control at a local level.
4.5 Link Aggregation Group (LAG) related functionality 4.3. OA&M related functionality
OAM mechanisms must be defined for GMPLS controlled E-LSPs. Since
the data plane is still Ethernet based, the mechanisms should
capitalize on existing [IEEE802.1ag] and [Y.1731] mechanisms.
Also, the solution should provide admin status control mechanism to
coordinate with Connectivity Fault Management (CFM) functionality
[IEEE802.1ag].
4.4. Protection and Restoration related functionality
1:1 protection, Shared protection and dynamic restoration should be
supported. Protection and Restoration may be triggered by Ethernet
OA&M function such as CC, AIS and RDI [IEEE802.1ag] , [Y.1731].
4.5. Link Aggregation Group (LAG) related functionality
Link Aggregation is beneficial functionality to realize reliable Link Aggregation is beneficial functionality to realize reliable
Ethernet label switched networks. The availability of connection Ethernet label switched networks. The availability of connection
between peer Ethernet switches can be enhanced in the case of between peer Ethernet switches can be enhanced in the case of single
single link failure, if member links of the LAG are diversely link failure, if member links of the LAG are diversely routed. In
routed. In this operational scenario, LAG provides for link protection this operational scenario, LAG provides for link protection
functionality. functionality.
The solution should include methodology to explicitly assign The solution should include methodology to explicitly assign the
the links forming LAG a desired link type (which is similar sense to links forming LAG a desired link type (which is similar sense to
assign link protection type described in [RFC3471]). assign link protection type described in [RFC3471]).
4.5.1 Failure or deletion of LAG member link 4.5.1. Failure or deletion of LAG member link
The solution should include functionality to prioritize Eth-LSPs, The solution should include functionality to prioritize Eth-LSPs,
specifically when total bandwidth of Eth-LSPs exceeds total bandwidth specifically when total bandwidth of Eth-LSPs exceeds total bandwidth
of healthy LAG members after the failure of one or more LAG member of healthy LAG members after the failure of one or more LAG member
links. links.
The solution should provide for rerouting an Eth-LSP setup over a The solution should provide for rerouting an Eth-LSP setup over a
failed member link in a LAG to another member link in the LAG. failed member link in a LAG to another member link in the LAG.
4.5.2 Recovery or addition of LAG member link 4.5.2. Recovery or addition of LAG member link
The solution should include functionality to re-optimize Eth-LSP The solution should include functionality to re-optimize Eth-LSP
paths after the addition of a LAG member link, i.e. reversion of paths after the addition of a LAG member link, i.e. reversion of
failed Eth-LSPs after the failure of the LAG member link, or failed Eth-LSPs after the failure of the LAG member link, or
reallocation of other Eth-LSPs traversing congested Links after reallocation of other Eth-LSPs traversing congested Links after the
the addition of LAG member link. addition of LAG member link.
4.6 Inter-domain Ethernet LSP 4.6. Inter-domain Ethernet LSP
The solution should take into account possible future extension The solution should take into account possible future extension to
to control inter-domain Eth-LSPs. Here, the possible extensions are control inter-domain Eth-LSPs. Here, the possible extensions are
Eth-LSPs traverse over Eth-LSPs traverse over
1) I-tagged service interfaces 1) I-tagged service interfaces
2) S-tagged service interfaces, and 2) S-tagged service interfaces, and
3) C-tagged service interfaces. 3) C-tagged service interfaces.
4.7 Multi-layer network 4.7. Multi-layer network
4.7.1 Dynamic formation of LAG 4.7.1. Dynamic formation of LAG
The solution should include dynamic formation of a LAG after the The solution should include dynamic formation of a LAG after the
creation or deletion of optical LSPs which interconnect ports of creation or deletion of optical LSPs which interconnect ports of
Ethernet switches. Ethernet switches.
4.7.2 Other requirements 4.7.2. Other requirements
The architecture and requirements for MPLS-GMPLS inter-working are The architecture and requirements for MPLS-GMPLS inter-working are
described in [Interwk-fwk] and [Interwk-req]. Some of the requirements described in [RFC5145] and [RFC5146]. Some of the requirements
described in [Interwk-req] are valid even for the case of GMPLS-GMPLS described in [RFC5146] are valid even for the case of GMPLS-GMPLS
interworking between Ethernet label switched network and L1 network. interworking between Ethernet label switched network and L1 network.
In other words, In other words,
1) End-to-End signaling of Eth-LSPs 1) End-to-End signaling of Eth-LSPs
2) Triggered establishment of L1 LSPs 2) Triggered establishment of L1 LSPs
3) Avoiding complexity and risks. 3) Avoiding complexity and risks.
should be satisfied even for GMPLS control plane for Ethernet. For should be satisfied even for GMPLS control plane for Ethernet. For
more details, see [Interwk-req] and MPLS-TE client network written more details, see [Interwk-req] and MPLS-TE client network written in
in the document should be understood as Ethernet client network. the document should be understood as Ethernet client network.
Regarding to routing issue, Regarding to routing issue,
1) Advertisement of Ethernet label switch network information
via L1 GMPLS networks 1) Advertisement of Ethernet label switch network information via L1
GMPLS networks
2) Selective Advertisement of Ethernet label switched network 2) Selective Advertisement of Ethernet label switched network
information via a Border node information via a Border node
should be satisfied even in the case of GMPLS-GMPLS inter-working. should be satisfied even in the case of GMPLS-GMPLS inter-working.
Note that there is significant difference between MPLS-TE and GMPLS Note that there is significant difference between MPLS-TE and GMPLS
controlled Ethernet from the view point of methodology to create controlled Ethernet from the view point of methodology to create
control channel. control channel.
4.8 Scalability 4.8. Scalability
The solution MUST be designed to scale according to following
metrics.
The solution MUST be designed to scale according to following metrics.
- Number of nodes - Number of nodes
- Number of TE-Links - Number of TE-Links
- Number of LSPs - Number of LSPs
- Number of service ports - Number of service ports
- Number of bundled S-VLANs mapped to I-SID and Eth-LSPs. - Number of bundled S-VLANs mapped to I-SID and Eth-LSPs.
5. Security considerations 5. Security Considerations
TBD The extension for GMPLS controlled Ethernet label switching should be
considered under the same security as current work. This extension
will not change the underlying security issues.
6. IANA considerations 6. IANA Considerations
TBD This document has no actions for IANA.
7. References 7. Acknowledgements
7.1 Normative References The authors would like to thank Mr. Allan McGuire, Mr. Jullien
Meuric, Mr. Lou Berger and Mr. Don Fedyk for their valuable comments.
[IEEE802.1ad] IEEE Computer Society, "Virtual Bridged Local Area 8. References
Networks - Amendment 4 : Provider Bridges", P802.1ad/D6.0,
Draft, Work in Progress
[IEEE802.1ah] "IEEE standard for Provider Backbone Bridges", work in 8.1. Normative References
progress.
[IEEE802.1Qay] "IEEE standard for Provider Backbone Bridges Traffic [IEEE802.1AB]
IEEE Standard for Local and Metropolitan Area Networks,
Station and Media Access Control Connectivity
Discovery
[IEEE802.1Qay]
"IEEE standard for Provider Backbone Bridges Traffic
Engineering", work in progress. Engineering", work in progress.
[RFC3945] E. Mannie (Editor), "Generalized Multi-Protocol Label [IEEE802.1ad]
Switching (GMPLS) Architecture", RFC 3945, October 2004. IEEE Computer Society, "Virtual Bridged Local Area
Networks - Amendment 4 : Provider Bridges", P802.1ad/D6.0,
Draft, Work in Progress.
[IEEE 802.1AB] "IEEE Standard for Local and Metropolitan Area [IEEE802.1ag]
Networks, Station and Media Access Control Connectivity IEEE Computer Society, "Virtual Bridged Local Area
Discovery". Networks - Amendment 5 : Connectivity Fault Management",
P802.1ag/D5.2, Draft, Work in Progress.
[IEEE802.3] IEEE Computer Society, "Amendment to Carrier Sense [IEEE802.1ah]
Multiple Access with Collision Detection (CAMS/CD) "IEEE standard for Provider Backbone Bridges", work in
Access Method and Physical Layer Specifications ? progress.
Aggregation of Multiple Link Segements, " P802.3ad,
March 2000.
[IEEE802.1ag] IEEE Computer Society, "Virtual Bridged Local Area [IEEE802.3]
Networks - Amendment 5 : Connectivity Fault Management", IEEE Computer Society, "Amendment to Carrier Sense
P802.1ag/D5.2, Draft, Work in Progress Multiple Access with Collision Detection (CAMS/CD) Access
Method and Physical Layer Specifications.
[RFC3471] L.Berger et al., "Generalized Multi-Protocol Label [MEF10.1] MEF, "Ethernet Services Attributes Phase2(MEF10.1)," http
Switching (GMPLS) - Signaling Functional Description", ://www.metroethernetforum.org/PDF_Documents/MEF10-1.pdf,
RFC 3471, January 2003. Nov. 2006.
7.2 Informative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[Interwk-frw] Shiomoto, K., Papadimitriou, D., Le Roux, J.L., [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
Brungard, D., Kumaki, K., Ali, Z., Oki, E., Inoue, I., (GMPLS) Signaling Functional Description", RFC 3471,
Otani, T., "Framework for MPLS-TE to GMPLS migration", January 2003.
draft-ietf-ccamp-mpls-gmpls-interwork-fmwk, work in
progress.
[Interwk-req] Kumaki, K., Otani, T., Okamoto, S., Fujihara, [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching
K., Ikejiri, Y., "Interworking Requirements to Support (GMPLS) Architecture", RFC 3945, October 2004.
operation of MPLS-TE over GMPLS Networks", draft-ietf-
ccamp-gmpls-mln-reqs, work in progress.
8. Acknowledgments [Y.1731] "ITU-T Y.1731".
The authors would like to thank Mr. Allan McGuire, Mr. Jullien 8.2. Informative References
Meuric, Mr. Lou Berger and Mr. Don Fedyk for their valuable
comments.
9. Authors' Addresses [RFC4124] Le Faucheur, F., "Protocol Extensions for Support of
Diffserv-aware MPLS Traffic Engineering", RFC 4124,
June 2005.
Wataru Imajuku (ed.) [RFC5145] Shiomoto, K., "Framework for MPLS-TE to GMPLS Migration",
RFC 5145, March 2008.
[RFC5146] Kumaki, K., "Interworking Requirements to Support
Operation of MPLS-TE over GMPLS Networks", RFC 5146,
March 2008.
Authors' Addresses
Wataru Imajuku (editor)
NTT Network Innovation Labs NTT Network Innovation Labs
1-1 Hikari-no-oka, Yokosuka, Kanagawa 1-1 Hikari-no-oka
Yokosuka, Kanagawa
Japan Japan
Phone: +81-(46) 859-4315 Phone: +81-(46) 859-4315
Email: imajuku.wataru@lab.ntt.co.jp Email: imajuku.wataru@lab.ntt.co.jp
Yoshiaki Sone Yoshiaki Sone
NTT Network Innovation Labs NTT Network Innovation Labs
1-1 Hikari-no-oka, Yokosuka, Kanagawa 1-1 Hikari-no-oka
Yokosuka, Kanagawa
Japan Japan
Phone: +81-(46) 859-2456 Phone: +81-(46) 859-2456
Email: sone.yoshiaki@lab.ntt.co.jp Email: sone.yoshiaki@lab.ntt.co.jp
Muneyoshi Suzuki Muneyoshi Suzuki
NTT Access Service System Labs NTT Access Service System Labs
1-6 Nakase, Mihama-ku, Chiba 1-6 Nakase
Mihama-ku, Chiba
Japan Japan
Phone: +81-(43) 211-8282 Phone: (43) 211-8282
Email: suzuki.muneyoshi@lab.ntt.co.jp Email: suzuki.muneyoshi@lab.ntt.co.jp
Kazuhiro Matsuda Kazuhiro Matsuda
NTT Network Innovation Labs NTT Network Innovation Labs
1-1 Hikari-no-oka, Yokosuka, Kanagawa 1-1 Hikari-no-oka
Yokosuka, Kanagawa
Japan Japan
Phone: +81-(46) 859-3177 Phone: (46) 859-3177
Email: matsuda.kazuhiro@lab.ntt.co.jp Email: matsuda.kazuhiro@lab.ntt.co.jp
Tomohiro Otani (editor)
KDDI Corporation
2-3-2 Nishi-shinjukuOhara
Shinjuku-ku, Tokyo 163-8003
Japan
Nabil Bitar (ed.) Phone: +81-(3) 3347-6006
Email: tm-otani@kddi.com
Kenichi Ogaki
KDDI R&D Laboratories, Inc.
2-1-15 Ohara
Kamifukuoka, Saitama 356-8502
Japan
Phone: +81-(49) 278-7897
Email: ogaki@kddilabs.jp
Nabil Bitar (editor)
Verizon Verizon
40 Sylvan Road 40 Sylvan Road
Waltham, MA 02451 Waltham, MA 02451
USA
Email: nabil.n.bitar@verizon.com Email: nabil.n.bitar@verizon.com
Kenichi Ogaki Full Copyright Statement
KDDI R&D Laboratories, Inc.
2-1-15 Ohara Fujimino-shi
Saitama, 356-8502 Japan
Phone: +81-49-278-7897
Email: ogaki@kddilabs.jp
Tomohiro Otani (ed.) Copyright (C) The IETF Trust (2008).
KDDI R&D Laboratories, Inc.
2-1-15 Ohara Fujimino-shi
Saitama, 356-8502 Japan
Phone: +81-49-278-7357 This document is subject to the rights, licenses and restrictions
Email: otani@kddilabs.jp contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Intellectual Property Statement 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 11, line 28 skipping to change at line 567
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Copyright Statement
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.
 End of changes. 101 change blocks. 
207 lines changed or deleted 286 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/