Internet DRAFT - draft-ietf-l2vpn-pbb-vpls-pe-model
draft-ietf-l2vpn-pbb-vpls-pe-model
INTERNET-DRAFT F. Balus (editor)
Intended Status: Informational Alcatel-Lucent
Expires: December 15, 2013 Ali Sajassi (editor)
Cisco
Nabil Bitar (editor)
Verizon
June 13, 2013
Extensions to VPLS PE model for Provider Backbone Bridging
draft-ietf-l2vpn-pbb-vpls-pe-model-07.txt
Abstract
IEEE 802.1 Provider Backbone Bridges (PBB) [IEEE.802.1Q-2011] defines
an architecture and bridge protocols for interconnection of multiple
Provider Bridge Networks (PBNs). PBB was defined in IEEE as a
connectionless technology based on multipoint VLAN tunnels. PBB can
be used to attain better scalability in terms of number of customer
MAC addresses and number of service instances that can be supported.
Virtual Private LAN Service (VPLS) [RFC4664] provides a framework for
extending Ethernet LAN services, using MPLS tunneling capabilities,
through a routed MPLS backbone without running RSTP or MSTP across
the backbone. As a result, VPLS has been deployed on a large scale in
service provider networks.
This draft discusses extensions to the VPLS Provider Edge (PE) model
required to incorporate desirable PBB components while maintaining
the Service Provider fit of the initial model.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Balus et al. Expires December 15, 2013 [Page 1]
INTERNET DRAFT Extensions to VPLS PE model for PBB June 13, 2013
Internet-Drafts are draft documents valid for a maximum of six months
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
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License Notice
Copyright (c) 2013 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. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. General terminology . . . . . . . . . . . . . . . . . . . . . . 4
3. PE Reference Model . . . . . . . . . . . . . . . . . . . . . . 6
4. Packet Walkthrough . . . . . . . . . . . . . . . . . . . . . . 9
5. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Efficient Packet replication in PBB VPLS . . . . . . . . . . . 11
7. PBB VPLS OAM . . . . . . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 12
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . . 13
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 13
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Balus et al. Expires December 15, 2013 [Page 2]
INTERNET DRAFT Extensions to VPLS PE model for PBB June 13, 2013
1. Introduction
IEEE 802.1 Provider Backbone Bridges (PBB) [IEEE.802.1Q-2011] defines
an architecture and bridge protocols for interconnection of multiple
Provider Bridge Networks (PBNs). PBB provides data plane hierarchy
and new addressing designed to improve the scalability of MAC
addresses and service instances in Provider Backbone Networks. A
number of Ethernet control plane protocols such as Rapid Spanning
Tree Protocol (RSTP), Multiple Spanning Tree Protocol (MSTP) and
Shortest Path Bridging (SPB), could be deployed as the core control
plane for loop avoidance and load balancing for PBB. The
applicability of these control protocols is out of scope for this
document.
Virtual Private LAN Service (VPLS) provides a solution for extending
Ethernet LAN services, using MPLS tunneling capabilities, through a
routed MPLS backbone without requiring the use of an native Ethernet
control plane protocol across the backbone. VPLS use of the
structured FEC 129 [RFC4762] also allows for inter-domain, inter-
provider connectivity and enables auto-discovery options across the
network improving the service delivery options.
A hierarchical solution for VPLS was introduced in [RFC4761] and
[RFC4762] for the purpose of improved scalability and to provide
efficient handling of packet replication. These improvements are
achieved by reducing the number of Provider Edge (PE) devices
connected in a full-mesh topology through the creation of two-tier
PEs. A User-facing PE (U-PE) aggregates all the CE devices in a
lower-tier access network and then connects to the Network-facing PE
(N-PE) device(s) deployed around the core domain. In VPLS, Media
Access Control (MAC) address learning and forwarding are done based
on customer MAC addresses (C-MACs), which poses scalability issues on
the N-PE devices as the number of VPLS instances (and thus customer
MAC addresses) increases. Furthermore, since a set of PWs is
maintained on a per customer service instance basis, the number of
pseudowires (PWs) required at N-PE devices is proportional to the
number of customer service instances multiplied by the number of N-PE
devices in the full-mesh set. This can result in scalability issues
(in terms of PW manageability and troubleshooting) as the number of
customer service instances grows.
This document describes how PBB can be integrated with VPLS to allow
for useful PBB capabilities while continuing to avoid the use of MSTP
in the backbone. The combined solution referred in this document as
PBB-VPLS results in better scalability in terms of number of service
instances, PWs and Customer MACs (C-MACs) that need to be handled in
the VPLS PEs.
Balus et al. Expires December 15, 2013 [Page 3]
INTERNET DRAFT Extensions to VPLS PE model for PBB June 13, 2013
Section 2 gives a quick terminology reference. Section 3 covers the
reference model for PBB VPLS PE. Section 4 describes the packet
walkthrough. Section 5 to 7 discusses the PBB-VPLS usage of existing
VPLS mechanisms - control plane, efficient packet replication,
Operations, Administration, and Maintenance (OAM).
2. General terminology
Some general terminology is defined here; most of the terminology
used is from [IEEE.802.1Q-2011], [RFC4664] and [RFC4026]. Terminology
specific to this memo is introduced as needed in later sections.
802.1ad: See PB.
802.1ah: See PBB.
B-BEB: A backbone edge bridge positioned at the edge of a provider
backbone bridged network. It contains a B-component that supports
bridging in the provider backbone based on Backbone MAC (B-MAC) and
B-TAG information
B-MAC: The backbone source or destination MAC address fields defined
in the PBB provider MAC encapsulation header.
BEB: A backbone edge bridge positioned at the edge of a provider
backbone bridged network. It can contain an I-component, B-component
or both I and B components.
B-component: A bridging component contained in backbone edge and core
bridges that bridges in the backbone space (B-MAC addresses, B-VLAN)
B-TAG: field defined in the PBB provider MAC encapsulation header
that conveys the backbone VLAN identifier information. The format of
the B-TAG field is the same as that of an 802.1ad S-TAG field.
B-Tagged Service Interface: This is the interface between a BEB and
BCB in a provider backbone bridged network. Frames passed through
this interface contain a B-TAG field.
B-VID: The specific VLAN identifier carried inside a B-TAG
B-VLAN: The backbone VLAN associated with a B-component.
B-PW: The pseudowire used to interconnect B-component instances.
CVID: The VLAN identifier in a customer VLAN.
Balus et al. Expires December 15, 2013 [Page 4]
INTERNET DRAFT Extensions to VPLS PE model for PBB June 13, 2013
DA: Destination Address
I-component: A bridging component contained in a backbone edge bridge
that bridges in the customer space (customer MAC addresses, S-VLAN)
IB-BEB: A backbone edge bridge positioned at the edge of a provider
backbone bridged network. It contains an I-component for bridging in
the customer space (customer MAC addresses, service VLAN IDs) and a
B-component for bridging the provider's backbone space (B-MAC, B-
TAG).
I-BEB: A backbone edge bridged positioned at the edge of a provider
backbone bridged network. It contains an I-component for bridging in
the customer space (customer MAC addresses, service VLAN IDs).
I-SID: The 24-bit service instance field carried inside the I-TAG. I-
SID defines the service instance that the frame should be "mapped
to".
I-TAG: A field defined in the PBB provider MAC encapsulation header
that conveys the service instance information (I-SID) associated with
the frame.
I-Tagged Service Interface: This the interface defined between the I
and B components inside an IB-BEB or between two B-BEB. Frames passed
through this interface contain an I-TAG field
PB: Provider Bridge IEEE amendment (802.1ad) to 802.1Q for "QinQ"
encapsulation and bridging of Ethernet frames [IEEE.802.1Q-2011].
PBB: Provider Backbone Bridge IEEE amendment (802.1ah) to 802.1Q for
"MAC tunneling" encapsulation and bridging of frames across a
provider network [IEEE.802.1Q-2011].
PBBN: Provider Backbone Bridged Network
PBN: Provider Bridged Network. A network that employs 802.1ad (QinQ)
technology.
SA: Source Address
S-TAG: A field defined in the 802.1ad QinQ encapsulation header that
conveys the service VLAN identifier information (S-VLAN).
S-Tagged Service Interface: This the interface defined between the
customer (CE) and the I-BEB or IB-BEB components. Frames passed
through this interface contain an S-TAG field.
Balus et al. Expires December 15, 2013 [Page 5]
INTERNET DRAFT Extensions to VPLS PE model for PBB June 13, 2013
S-VLAN: The specific service VLAN identifier carried inside an S-TAG
SVID: The VLAN identifier in a service VLAN.
TAG: In Ethernet a header immediately following the Source MAC
Address field of the frame.
3. PE Reference Model
The following gives a short primer on Provider Backbone Bridge (PBB)
before describing the PE reference model for PBB-VPLS. The internal
components of a PBB bridge module are depicted in Figure 1.
+-------------------------------+
| PBB Bridge Model |
| |
+---+ | +------+ +-----------+ |
|CE |---------|I-Comp|------| | |
+---+ | | | | |--------
| +------+ | | |
| o | B-Comp | |
| o | |--------
| o | | |
+---+ | +------+ | | |
|CE |---------|I-Comp|------| |--------
+---+ ^ | | | ^ | | | ^
| | +------+ | +-----------+ | |
| +------------|------------------+ |
| | |
| | |
S-tagged I-tagged B-tagged
Service I/F Service I/F Service Interface (I/F)
Figure 1: PBB Bridge Model
Provider Backbone Bridges (PBBs) [IEEE.802.1Q-2011] offers a scalable
solution for service providers to build large bridged networks. The
focus of PBB is primarily on improving two main areas with provider
Ethernet bridged networks:
- MAC-address table scalability
- Service instance scalability
To obviate the above two limitations, PBB introduces a hierarchical
network architecture with associated new frame formats which extend
the work completed by Provider Bridges (PB). In the PBBN
architecture, customer networks (using PB) are aggregated into
Balus et al. Expires December 15, 2013 [Page 6]
INTERNET DRAFT Extensions to VPLS PE model for PBB June 13, 2013
Provider Backbone Bridge Networks (PBBNs) which utilize the IEEE PBB
frame format. The frame format employs a MAC tunneling encapsulation
scheme for tunneling customer Ethernet frames within provider
Ethernet frames across the PBBN. A VLAN identifier (B-VID) is used to
segregate the backbone into broadcast domains and a new 24-bit
service identifier (I-SID) is defined and used to associate a given
customer MAC frame with a provider service instance (also called the
service delimiter). It should be noted that in [IEEE.802.1Q-2011]
there is a clear segregation between provider service instances
(represented by I-SIDs) and provider VLANs (represented by B-VIDs)
which was not the case for PB.
As shown in the figure 1, a PBB bridge may consist of a single B-
component and one or more I-components. In simple terms, the B-
component provides bridging in provider space (B-MAC, B-VLAN) and the
I-component provides bridging in customer space (C-MAC, S-VLAN). The
customer frame is first encapsulated with the provider backbone
header (B-MAC, B-tag, I-tag); then, the bridging is performed in the
provider backbone space (B-MAC, B-VLAN) through the network till the
frame arrives at the destination BEB where it gets de-encapsulated
and passed to the CE. If a PBB bridge consists of both I & B
components, then it is called IB-BEB and if it only consists of
either B-component or I-component, then it is called B-BEB or I-BEB
respectively. The interface between an I-BEB or IB-BEB and a CE is
called S-tagged service interface and the interface between an I-BEB
and a B-BEB (or between two B-BEBs) is called I-tagged service
interface. The interface between a B-BEB or IB-BEB and a Backbone
Core Bridge (BCB) is called B-Tagged service interface.
To accommodate the PBB components the VPLS model defined in [RFC4664]
is extended as depicted in figure 1.
Balus et al. Expires December 15, 2013 [Page 7]
INTERNET DRAFT Extensions to VPLS PE model for PBB June 13, 2013
+----------------------------------------+
| PBB-VPLS-capable PE model |
| +---------------+ +------+ |
| | | |VPLS-1|------------
| | |==========|Fwdr |------------ PWs
+--+ | | Bridge ------------ |------------
|CE|-|-- | | +------+ |
+--+ | | Module | o |
| | | o |
| | (PBB | o |
| | bridge) | o |
| | | o |
+--+ | | | +------+ |
|CE|-|-- | ------------VPLS-n|-------------
+--+ | | |==========| Fwdr |------------- PWs
| | | ^ | |-------------
| +---------------+ | +------+ |
| | |
+-------------------------|--------------+
LAN emulation Interface
Figure 2: PBB-VPLS capable PE Model
The PBB Module as defined in [IEEE.802.1Q-2011] specification is
expanded to interact with VPLS Forwarders. The VPLS Forwarders are
used in [RFC4762] to build a PW mesh or a set of spoke-PWs
(Hierarchical VPLS (HVPLS) topologies). The VPLS instances are
represented externally in the MPLS context by a Layer 2 Forwarding
Equivalence Class (L2FEC) which binds related VPLS instances
together. VPLS Signaling advertises the mapping between the L2FEC and
the PW labels and implicitly associates the VPLS bridging instance to
the VPLS Forwarders [RFC4762].
In the PBB-VPLS case the backbone service instance in the B-component
space(B-VID) is represented in the backbone MPLS network using a VPLS
instance. Same as for the regular VPLS case, existing signaling
procedures are used to generate through PW labels the linkage between
VPLS Forwarders and the backbone service instance.
Similarly with the regular HVPLS, another L2FEC may be used to
identify the customer service instance in the I-component space. This
will be useful for example to address the PBB-VPLS N-PE case where
HVPLS spokes are connecting the PBB-VPLS N-PE to a VPLS U-PE.
It is important to note that the PBB-VPLS solution inherits the PBB
service aggregation capability where multiple customer service
Balus et al. Expires December 15, 2013 [Page 8]
INTERNET DRAFT Extensions to VPLS PE model for PBB June 13, 2013
instances may be mapped to a backbone service instance. In the PBB-
VPLS case this means multiple customer VPNs can be transported using
a single VPLS instance corresponding to the backbone service
instance, thus reducing substantially resource consumption in the
VPLS core.
4. Packet Walkthrough
Since the PBB bridge module inherently performs forwarding, the PE
reference model of Figure 2 can be expanded as the one shown in
Figure 3.
Furthermore, the B-component is connected via several virtual
interfaces to the PW Forwarder module. The function of PW Forwarder
is defined in [RFC3985]. In this context, the PW Forwarder simply
performs the mapping of the PWs to the Virtual Interface on the B-
component without the need for any MAC lookup.
This simplified model takes full advantage of PBB module where all
the PBB[IEEE.802.1Q-2011] procedures including the C-MAC/B-MAC
forwarding and PBB encapsulation/de-capsulation takes place and thus
avoids specifying any of these functions in here.
Because of text-based graphics, the Figure 3 only shows PWs on the
core-facing side; however, in case of MPLS access with spoke PWs, the
PE reference model is simply extended to include the same PW
Forwarder function on the access-facing side. To avoid cluttering the
figure, the access-side PW Forwarder (Fwdr) is not depicted without
loss of any generality.
Balus et al. Expires December 15, 2013 [Page 9]
INTERNET DRAFT Extensions to VPLS PE model for PBB June 13, 2013
+------------------------------------------------+
| PBB-VPLS-capable PE model |
| +---------------+ +------+ |
| | | | | |
| +------+ | ======== ---------
+--+ | | | | | | --------- PWs
|CE|-|-- | I- ==== ======== PW ---------
+--+ | | comp | | | | Fwdr |
| +------+ | | | --------- PWs
| | B-Comp ======== ---------
| | | ^ | | |
| +------+ | | | +------+ |
+--+ | | I- | | OOOOOOOOOOOOOOOOOOOOOOOO B-tag
|CE|-|-- | comp ==== | | | I/Fs
+--+ | | |^ | OOOOOOOOOOOOOOOOOOOOOOOO
| +------+| | | | |
| | +---------------+ | |
| | | |
+-----------|--------------------|---------------+
| |
Internal I-tag I/Fs Virtual Interfaces (I/Fs)
+----------+ +------------+
|CMAC DA,SA| | PSN header |
|----------| |------------|
|SVID, CVID| | PW Label |
|----------| |------------|
| Payload | | BMAC DA,SA |
+----------+ |------------|
| PBB I-tag |
|------------|
| CMAC DA,SA |
|------------|
| SVID, CVID |
|------------|
| Payload |
+------------+
Figure 3: Packet Walkthrough for PBB VPLS PE
In order to better understand the data plane walkthrough let us
consider the example of a PBB packet arriving over a Backbone
pseudowire (B-PW). The PSN header is used to carry the PBB
encapsulated frame over the backbone while the PW Label will point to
the related Backbone Service Instance (B-SI), same as for regular
VPLS. The PW Label has in this case an equivalent role with the
Backbone VLAN id on the PBB B-tagged interface.
Balus et al. Expires December 15, 2013 [Page 10]
INTERNET DRAFT Extensions to VPLS PE model for PBB June 13, 2013
An example of the PBB packet for regular Ethernet PW is depicted in
Figure 3 on the right hand side. The MPLS packet from MPLS core
network is received by the PBB-VPLS PE. The PW Forwarder function of
the PE uses PW label to derive the virtual interface-id on the B-
component and then after removing the PSN and PW encapsulation, it
passes the packet to the B-component. From there on, the processing
and forwarding is performed according to the PBB [IEEE.802.1Q-2011]
where bridging based on backbone MAC (B-MAC) Destination Address DA
is performed which result in one of the three outcomes:
1. The packet is forwarded to a physical interface on the B-
component. In this case, the PBB Ethernet frame is forwarded as
is.
2. The packet is forwarded to a virtual interface on the B-
component. This is not typically the case because of a single
split-horizon group within a VPLS instance; however, if there is
more than one split-horizon group, then such forwarding takes
place. In this case, the PW Forwarder module adds the PSN and PW
labels before sending the packet out.
3. The packet is forwarded toward the access side via one of the I-
tagged service interfaces connected to the corresponding I-
components. In this scenario, the I-component removes the B-MAC
header according to PBB [IEEE.802.1Q-2011] and bridges the packet
using C-MAC DA.
4. If the destination B-MAC is an unknown or a Group MAC address
(Multicast or Broadcast), then the B-component floods the
packet to one or more of the three destinations described above.
5. Control Plane
The control plane procedures described in [RFC6074], [RFC4761] and
[RFC4762] can be re-used in a PBB-VPLS to setup the PW infrastructure
in the service provider and/or customer bridging space. This allows
porting the existing control plane procedures (e.g. BGP Auto-
discovery (BGP-AD), PW setup, VPLS MAC Flush, PW OAM) for each
domain.)
6. Efficient Packet replication in PBB VPLS
The PBB VPLS architecture takes advantage of the existing VPLS
features addressing packet replication efficiency. HVPLS hierarchy
may be used in both customer and backbone service instances to reduce
the redundant distribution of packets over the core. IGMP and PIM
snooping may be applied on a per customer service instance to control
Balus et al. Expires December 15, 2013 [Page 11]
INTERNET DRAFT Extensions to VPLS PE model for PBB June 13, 2013
the distribution of the Multicast traffic to non-member sites.
IEEE 802.1Q [IEEE.802.1Q-2011] specifies the use of Multiple MAC
registration (MMRP) protocol for flood containment in the backbone
instances. The same solution can be ported in the PBB-VPLS solution.
Further optimizations of the packet replication in PBB-VPLS are out
of the scope of this draft.
7. PBB VPLS OAM
The existing VPLS, PW and MPLS OAM procedures may be used in each
customer or backbone service instance to verify the status of the
related connectivity components.
PBB OAM procedures make use of the IEEE Ethernet Connectivity Fault
Management (CFM) [IEEE.802.1Q-2011] and ITU-T Y.1731 [Y.1731] tools
in both I-component and B-component.
Both set of tools (PBB and VPLS) may be used for the combined PBB-
VPLS solution.
8. Security Considerations
No new security issues are introduced beyond those that are described
in [RFC4761] and [RFC4762].
9. IANA Considerations
IANA does not need to take any action for this draft.
10. References
10.1. Normative References
[RFC4761] Kompella, K. and Rekhter, Y. (Editors), "Virtual Private
LAN Service (VPLS) Using BGP for Auto-Discovery and
Signaling", RFC 4761, January 2007.
[RFC4762] Lasserre, M. and Kompella, V. (Editors), "Virtual Private
LAN Service (VPLS) Using Label Distribution Protocol (LDP)
Signaling", RFC 4762, January 2007.
[RFC6074] E. Rosen, et Al. "Provisioning, Autodiscovery and Signaling
in L2VPNs", RFC 6074, January 2011
Balus et al. Expires December 15, 2013 [Page 12]
INTERNET DRAFT Extensions to VPLS PE model for PBB June 13, 2013
10.2. Informative References
[RFC3985] Bryant, S. and Pate, P. (Editors)," Pseudo Wire Emulation
Edge-to-Edge (PWE3) Architecture", RFC 3985, May 2005.
[RFC4664] Andersson, L. and Rosen, E. (Editors),"Framework for Layer
2 Virtual Private Networks (L2VPNs)", RFC 4664, Sept 2006
[IEEE.802.1Q-2011] IEEE, "IEEE Standard for Local and metropolitan
area networks -- Media Access Control (MAC) Bridges and
Virtual Bridged Local Area Networks", IEEE Std 802.1Q,
2011.
[Y.1731] Y.1731 (2006), ITU-T Recommendation, OAM functions and
mechanisms for Ethernet based networks
[RFC4026] Andersson, L. et Al., "Provider Provisioned Virtual Private
Network (VPN) Terminology", RFC 4026, May 2005.
11. Contributors
The following authors contributed to this document: John Hoffmans
(KPN), Geraldine Calvignac (France Telecom), Olen Stokes (Extreme
Networks), Raymond Zhang and Matthew Bocci (Alcatel-Lucent).
12. Acknowledgments
The authors would like to thank Wim Henderickx, Mustapha Aissaoui,
Dimitri Papadimitriou, Pranjal Dutta, Jorge Rabadan, Maarten Vissers
and Don Fedyk for their insightful comments and probing questions.
Authors' Addresses
Ali Sajassi
Cisco
170 West Tasman Drive
San Jose, CA 95134, U.S.
Email: sajassi@cisco.com
Nabil Bitar
Verizon
40 Sylvan Road
Waltham, MA 02145
Email: nabil.bitar@verizon.com
Florin Balus
Alcatel-Lucent
Balus et al. Expires December 15, 2013 [Page 13]
INTERNET DRAFT Extensions to VPLS PE model for PBB June 13, 2013
701 E. Middlefield Road
Mountain View, CA, USA 94043
Email: florin.balus@alcatel-lucent.com
Matthew Bocci
Alcatel-Lucent,
Voyager Place
Shoppenhangers Road
Maidenhead
Berks, UK
e-mail: matthew.bocci@alcatel-lucent.com
Raymond Zhang
Alacatel-Lucent
EMail: raymond.zhang@alcatel.com
Geraldine Calvignac
Orange
2, avenue Pierre-Marzin
22307 Lannion Cedex
France
Email: geraldine.calvignac@orange.com
John Hoffmans
KPN
Regulusweg 1
2516 AC Den Haag
Nederland
Email: john.hoffmans@kpn.com
Olen Stokes
Extreme Networks
PO Box 14129
RTP, NC 27709
USA
Email: ostokes@extremenetworks.com
Balus et al. Expires December 15, 2013 [Page 14]
