L2VPN Working Group F. Balus
Internet Draft M. Bocci
Intended Status: Proposed Standard M. Aissaoui
Expires: January 2008 Alcatel-Lucent
John Hoffmans
KPN
Geraldine Calvignac
France Telecom
Raymond Zhang
British Telecom
Nabil Bitar
Verizon
July 8, 2007
VPLS Extensions for Provider Backbone Bridging
draft-balus-l2vpn-vpls-802.1ah-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
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 Section 6 of 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.
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.
This Internet-Draft will expire on January 8, 2008.
Abstract
Balus, et. al Expires January 8, 2008 [Page 1]
Internet-Draft VPLS Extensions for PBB July 2007
IEEE 802.1ah draft standard [IEEE802.1ah], also known as Provider
Backbone Bridges (PBB) 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. MSTP is used as the core control plane for
loop avoidance and load balancing. As a result, the coverage of the
solution is limited by STP scale in the core of large service
provider networks.
Virtual Private LAN Service (VPLS) [RFC4762] provides a solution for
extending Ethernet LAN services, using MPLS tunneling capabilities,
through a routed MPLS backbone without running (M)STP 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 model required to
incorporate desirable PBB components while maintaining the Service
Provider fit of the initial model.
Conventions used in this document
In examples, "C:" and "S:" indicate lines sent by the client and
server respectively.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
Table of Contents
1. Terminology....................................................3
2. Introduction...................................................3
3. Reference Model................................................4
4. Deployment Scenarios...........................................6
5. Data Plane.....................................................8
6. Auto-Discovery.................................................8
7. Signaling......................................................8
7.1. MAC Address Withdraw.....................................10
7.2. Flood Containment in the Backbone VPLS...................10
8. Multicast Handling............................................11
9. Resiliency....................................................11
10. OAM..........................................................11
11. Security Considerations......................................12
12. IANA Considerations..........................................12
Balus, et al. Expires January 8, 2008 [Page 2]
Internet-Draft VPLS Extensions for PBB July 2007
13. Acknowledgments..............................................12
14. References...................................................13
14.1. Normative References....................................13
14.2. Informative References..................................13
Author's Addresses...............................................13
Full Copyright Statement.........................................14
Intellectual Property Statement..................................15
Acknowledgment...................................................15
1. Terminology
[IEEE802.1ah] provides terminology for Provider Backbone Bridging.
This document defines the following additional terms:
B-x: a component of the Backbone domain
B-VPLS: a VPLS that operates in the Backbone MAC domain, carrying one
or multiple I-VPLS instances
B-VSI: A VPLS Service Instance (VSI) that participates in a B-VPLS
B-FEC: A FEC associated with a certain B-VSI association
B-PW: A PW interconnecting two B-VSI Instances
I-x: a component of the customer domain
I-VPLS: a VPLS that participates in the customer MAC layer - i.e. it
uses the customer MAC addresses (basically the destination address)
to switch Ethernet frames
I-VSI: A VPLS Service Instance (VSI) that participates in an I-VPLS
I-FEC: A FEC associated with a certain I-VSI association
I-PW: A PW interconnecting two I-VSI Instances
PBB VPLS: a PBB Service built around an I-VPLS component aggregated
through a B-VPLS "tunnel"
PBB PE: a PE that contains an I-VSI and a related B-VSI.
2. Introduction
The IEEE model for PBB is organized around a B-component handling the
provider backbone layer and an I-component concerned with the mapping
Balus, et al. Expires January 8, 2008 [Page 3]
Internet-Draft VPLS Extensions for PBB July 2007
of Customer/Provider Bridge (QinQ) domain (e.g. MACs, VLANs) to the
provider backbone (e.g. B-MACs, B-VLANs): i.e. the I-component
contains the boundary between the Customer and Backbone MAC domains.
PBB encapsulates customer payload in a provider backbone Ethernet
header, providing for Customer MAC hiding capabilities.
PBB requires the use of MSTP as the core control plane (B-domain) for
loop avoidance and load balancing. As a result, the coverage of the
solution is limited by STP scale in the core of large service
provider networks.
VPLS provides a solution for extending Ethernet LAN services, using
MPLS tunneling capabilities, through a routed MPLS backbone without
running (M)STP 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.
VPLS creates an emulated LAN Segment using as building blocks a set
of Virtual Switch Instances (VSIs) interconnected using Virtual Links
- i.e. based on Pseudo Wires (PWs) or native Ethernet.
In a large scale deployment, there might be a need to split the
backbone domain into two or more domains using the Hierarchical-VPLS
(H-VPLS) model described in [RFC4762]. This may be required for
administrative reasons, or to provide efficient handling of packet
replication. In this context VPLS scalability may be improved by
hiding the customer MAC addresses at the edge PEs so that the core
PEs (e.g. PE-rs) handle just the Provider MAC addresses.
This document proposes simple extensions to the VPLS model to allow
for selective inclusion of useful PBB capabilities while continuing
to avoid the use of MSTP in the backbone. The proposed solution
accommodates though the use of native Ethernet model, MSTP-based for
the PBBN [IEEE802.1ah] should a provider choose to deploy it.
The basic functions do not require changes to existing PW, MPLS data
or control plane. In this document, we are proposing some optional
extensions to PW signaling to optimize the MAC Withdraw process and
to address flood containment in the backbone VPLS.
3. Reference Model
At a high level, a PBB VPLS may be represented as one or more I-
VPLSes interconnected via a Backbone VPLS (B-VPLS) that may be seen
as a multi-point tunnel. Inside a particular PBB PE, a "PBB VPLS VSI"
may be modeled as an "I-VSI" mapped to a "B-VSI" operating on
Balus, et al. Expires January 8, 2008 [Page 4]
Internet-Draft VPLS Extensions for PBB July 2007
Customer and the Backbone MAC layer, respectively, as depicted in
Figure 1. The PBB PE provides equivalent function with a PBB IB-BEB -
see [IEEE802.1ah].
,,.--.,,
,-` `',
- '
' \
| MPLS |
| |
, /
. /
/., _./ |
| /`''--''` | |
| | | |
+-\-\--+ +--\-\-+
| B-PW | | B-PW |
+-----| |----| |-----+
| +------+ +---.--+ |
| `. ,.., ` |
| ' `-` |
,.-., | ,.B-VSI | |
,' `+-------+ ,-` . / |
/ | | .'` `/.` |
| PBBN | B-ETH | ` | PBB PE |
\ | | ,- |
`. ,+-------+ / ` |
`'-'` | ' `. |
| ,' I-VSI . |
| --.--.-----' |
| .` | `. |
| +-----`+ +--\---+ +-'----+ |
| | | | | | | |
+--| I-PW |-| I-ETH|-| I-Q |--+
| | | | | |
+--/---+ +--_---+ +------+
` / \ `. `
,.-/, / \ ,.'/,
,' `. - ' ,' `.
/ , CE CE / ,
| I-VPLS | Q-in-Q
\ ` \ `
`. ,' `. ,'
`'-'` `'-'`
Figure 1: "PBB VPLS VSI" reference model
This representation of PBB VPLS components is an abstract model to be
used in this document to help the solution description. It is up to
Balus, et al. Expires January 8, 2008 [Page 5]
Internet-Draft VPLS Extensions for PBB July 2007
the implementations to optimize the functions described in this
document as long as they provide for solution interoperability.
The I-VSIs may be mapped 1:1 or many:1 (m:1) to the B-VSIs. PBB
Customer MAC hiding and aggregation functions are provided by
encapsulating the Customer MAC frame into a Provider Ethernet Header
and by mapping the Customer MACs to Backbone MACs. An I-component
Service ID (ISID) may be used to provide additional multiplexing
capabilities (m:1 model).
Pseudo Wires or native Ethernet virtual ports may be associated with
these entities in Backbone and/or Customer domains. In Figure 1 they
are tagged with B-PW/B-ETH and I-PW/I-ETH, respectively. Each of
these domains may use a full mesh, a hub and spoke topology or a
combination as described in [RFC4762].
4. Deployment Scenarios
VPLS is being deployed in the Service Provider networks as a solution
for Ethernet Multi-point service spanning multiple network domains
(e.g. Metro Ethernet networks interconnected via a
national/international MPLS backbone). Figure 2 shows an example of
three VPLS domains where PE 3 and PE4 are the core PEs.
For some very large Layer 2 VPNs (i.e., with large number of MAC
addresses), it may make sense to use a PBB "VPLS VSI" in the edge PEs
(1, 2, 5 and 6) to hide the customer MAC addresses from the core PEs.
Dynamically signaled B-PWs are used to provide B-VSI interconnect
over a routed MPLS backbone, eliminating the need for per service
configuration throughout the core.
Carrier of Carrier Services may be sold using this additional
hierarchy of services where the a Carrier may sell a L2 Service using
its MPLS infrastructure but use PBB to separate the addressing of its
Carrier customer from its backbone.
IEEE 802.1ah specification allows for 1:1 or m:1 I-component(s) to B-
component mapping. The former option (1:1) may be chosen by a service
provider who is content with the level of service multiplexing
provided by the B-PWs. In this particular scenario there is no need
for using an ISID for identifying the service: i.e. the B-PW fully
identifies the end customer VSI (I-VSI).
Balus, et al. Expires January 8, 2008 [Page 6]
Internet-Draft VPLS Extensions for PBB July 2007
_,,..--..,,,
,-'` `'-,
.` `'
,' `.
/ VPLS ,
| Domain 2 |
\ `
`. `
', _-`
+------`-,, _,-`-------+
| ,-, | ``'''--'''`` | ,-, |
PE3 | | B | | | | B | | PE4
| | | | | | | |
| `'' | | `'' |
+-,--,,-+ +--,--,,+
,' \ ,' \
/ \ / \
| VPLS | | VPLS |
| Domain 1 | | Domain 3 |
| | | |
\ / \ /
`. / `. /
+------`-,,+-------+ +-------+'-'+-------+
| ,-, | | ,-, | | ,-, | | ,-, |
| | B | | | | B | | | | B | | | | B | |
| | | | | | | | | | | | | | | |
| `'' | | `'' | | `'' | | `'' |
| I1 I2 | | I1 I3 | | I1 I2 | | I1 I3 |
+-------+ +-------+ +-------+ +-------+
PE1 PE2 PE6 PE5
Figure 2 PBB VPLS Topology for m:1 use case
Alternatively the ISID may be used to provide an additional level of
service multiplexing, on top of the B-PW service label.
In the (m:1) model, there are use cases where the I-VPLS domains that
share the same B-VPLS overlap but in most practical scenarios that is
not the case. A broadcast and flood containment solution in that case
will be required.
While this document is focused on PBB VPLS solution where B-PWs are
used as core infrastructure, the model allows for native Ethernet
Access (QinQ and/or PBB) or even a full PBB solution to be deployed
using just the I-ETH or B-ETH interconnects between the related I-
VSIs and respectively B-VSIs. However, these are the subject of
[IEEE802.1ah] and are out of the scope of this document. Description
Balus, et al. Expires January 8, 2008 [Page 7]
Internet-Draft VPLS Extensions for PBB July 2007
of the framework and requirements for interoperability between the
IEEE and VPLS model is given in [VPLS-PBB-Interop].
Specific service provider requirements often define the boundaries of
PBB and VPLS domains within their networks. It is not in the scope of
this document to specify how far in the Metro Area Network (MAN) or
the Wide Area Network (WAN) PBB and VPLS boundaries extend. The PBB
VPLS may co-exist in the same PE with non PBB services (i.e., regular
VPLS or VLLs using MPLS PW where PBB Customer MAC hiding and
aggregation functions are not required).
5. Data Plane
The core PEs (PE3 and PE4 in Figure 2) do not need to be aware about
the PBB encapsulation (i.e., just the regular Backbone Ethernet
header is used to forward the Ethernet frames). Existing VPLS and
PWE3 procedures, including Multi-Segment PWs (MS-PW) apply.
At the PBB PEs, additional PBB encapsulation/de-encapsulation is
required when passing the frame between the I and B components. ISID
look-up is used to differentiate between I-VSI entities whenever
(m:1) model is used.
6. Auto-Discovery
Existing VPLS discovery procedures as per [L2VPN-Sig] may be used in
the B-VPLS domain and even inside each local I-VPLS domain.
End-to-end auto-discovery of I-VPLS instances coincides with BVPLS
discovery for the 1:1 I-VSI to B-VSI model. The (m:1) model requires
further examination.
7. Signaling
The setup of the B-PWs and/or the I-PWs between related VSI entities
may be achieved using the existing PWE3 procedures - see [RFC4762].
FEC 128 or FEC 129 may be used to identify each VSI instance
accordingly.
Lack of congruency among customer VPN domains might motivate Service
Providers to deploy an (1:1) model (I to B) as a simple solution for
flood containment. For this particular scenario, the backbone FEC and
related PW Service Labels fully identify the PBB VPLS in the control
and data plane, respectively. There is no need for the ISID to be
configured, signaled or used in the data plane to provide service
multiplexing/demultiplexing.
Balus, et al. Expires January 8, 2008 [Page 8]
Internet-Draft VPLS Extensions for PBB July 2007
For the m:1 (I to B) model it is useful to include in the LDP
signaling the I-VPLS information associated with the PBB VPLS
instances. The ISID information and the associated BMAC on a certain
PBB PE may be signaled when required using a new LDP TLV, the "PBB
TLV".
This TLV may be used for the m:1 model in conjunction with the B-VPLS
FEC TLV to invoke MAC table pre-mature aging upon topology changes in
the related B-VPLS infrastructure or attached networks and to achieve
broadcast and flood containment per service instance as described in
section 7.1 and 7.2, respectively.
A suggested PBB TLV structure is given below:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0| PBB TLV (TBD) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLV Type | Length | Variable Length Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Variable Length Value |
| " |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The PBB sub-TLV type values are TBD. The Length field is used to
define the length of the PBB sub-TLV including the type and the
length itself. Processing of the sub-TLVs should continue when
unknown ones are encountered, and they MUST be silently ignored.
One or more of the following sub-TLV may be included in the PBB TLV:
- I-VPLS ID sub-TLV type
A 4 octet value containing the ISID value of the related I-VPLS
- B-MAC Address sub-TLV type
Balus, et al. Expires January 8, 2008 [Page 9]
Internet-Draft VPLS Extensions for PBB July 2007
A 6 octet value containing the BMAC address associated with the I-
VPLS ID(s) on the sender node.
Usage of this optional new TLV is specified in the following
sections.
7.1. MAC Address Withdraw
The use of Address Withdraw message with MAC List TLV is proposed in
[RFC4762] as a way to expedite removal of MAC addresses as the result
of a topology change (e.g. failure of a primary link or of a VPLS PE
used as one in a pair of switches in a dual-homing use case). These
existing procedures apply to B-VPLS and I-VPLS domains.
When it comes to reflecting failures in access networks across the
core (i.e. B-VPLS) domain certain additions should be considered as
described below.
MAC Switching in PBB is based on the mapping of customer MACs to
Provider MAC(s). A topology change in the access (I-domain) should
just invoke the flushing of Customer MAC entries in PBB PEs' FIB(s)
associated with the I-VPLS(s) impacted by the failure. Further
optimizations may consider flushing just the Customer MAC addresses
that are mapped to a specific destination BMAC.
These goals may be achieved by adding the PBB TLV associated with the
affected I-VPLS(s) in the Address Withdraw message to indicate the
particular domain(s) requiring MAC flush. At the other end, the
receiving PBB PEs may use the ISID(s) and/or the BMAC information to
flush only the related FIB entry/entries (customer/I-domain)
associated with these I-SIDs and learnt via the bridges with these
BMAC addresses.
7.2. Flood Containment in the Backbone VPLS
PBB is using a special Backbone Group MAC (BMAC) address every time
flooding in the B-domain is required. This BMAC is built (see
[IEEE802.1ah]) using a group OUI assigned for PBB usage followed by
the ISID value in the last 24 bit of the MAC address.
As I-VPLS components are added to a certain Backbone VPLS, the new
components identifying the PBB Service Instance may be used to
advertise the presence of a specific ISID on a certain PBB PE and
throughout the BVPLS core. At the Backbone VPLS PEs, the ISID
information may be used to build a flooding tree in the data plane
that will deliver traffic through the BVPLS infrastructure just to
Balus, et al. Expires January 8, 2008 [Page 10]
Internet-Draft VPLS Extensions for PBB July 2007
the PBB PEs where the IVPLS endpoints are present. The dissemination
of the ISID information is achieved through the use of PBB TLV.
The above procedure assumes the same ISID value is used to identify
the customer VPN across the BVPLS domain. Inter-provider scenarios
will be discussed in a future version of the document.
8. Multicast Handling
PBB MAC hiding may create difficulties for identifying customer
Multicast exchanges. It is important to be able to support both
regular and PBB VPLSes. That way the customer VPNs requiring large
volume of Multicast may be addressed using regular VPLS, allowing for
easy multicast snooping throughout the VPLS infrastructure.
Alternatively, the optimization for Flood Containment may be expanded
to allow for efficient Multicast handling in the BVPLS
infrastructure: i.e. Group BMAC addresses may be assigned per
Multicast tree to ensure efficient Multicast distribution on a per I-
VPLS basis.
9. Resiliency
[IEEE802.1ah] recommends the use of Provider MSTP (P-MSTP) to ensure
loop free topology for connectionless forwarding throughout PBBN.
Using BVPLS infrastructure instead of native Ethernet core eliminates
the need for backbone P-MSTP through the use of a full mesh of PWs
with split-horizon and/or via the H-VPLS scheme (Primary/Standby PWs)
- see [RFC4762].
On the access side, for a PB network or a CE device dually connected
to PBB PEs, a loop spanning both I and B domains may occur. An STP-
based or a local mechanism may be used to break this loop.
A solution that does not imply running MSTP end-to-end may involve
the MAC Withdraw scheme described in the signaling section to speed-
up data plane convergence upon topology changes.
10. OAM
Existing VPLS OAM tools may be used in each I-VPLS and B-VPLS domain.
Details of the required OAM tools and the correlation between these
two domains are out of scope of this draft.
Balus, et al. Expires January 8, 2008 [Page 11]
Internet-Draft VPLS Extensions for PBB July 2007
11. Security Considerations
This section will be added in a future version.
12. IANA Considerations
This document proposes the use of a new LDP TLV and related sub-TLV.
Suggested values TBD.
13. Acknowledgments
The authors gratefully acknowledge the contributions of Wim
Henderickx, Dimitri Papadimitriou and Maarten Vissers.
Balus, et al. Expires January 8, 2008 [Page 12]
Internet-Draft VPLS Extensions for PBB July 2007
14. References
14.1. Normative References
[RFC4762] Lasserre, M. and Kompella, V. (Editors), "Virtual Private
LAN Service (VPLS) Using Label Distribution Protocol (LDP)
Signaling", RFC 4762, January 2007.
[IEEE802.1ah] IEEE Draft P802.1ah/D3.5 "Virtual Bridged Local Area
Networks, Amendment 6: Provider Backbone Bridges", Work in
Progress, April 19, 2007
[VPLS-PBB-Interop] A. Sajassi, et Al. "VPLS Interoperability with
Provider Backbone Bridges", draft-sajassi-l2vpn-vpls-pbb-
interop-00.txt, March 2007 ( work in progress ).
14.2. Informative References
[L2VPN-Sig] E. Rosen, et Al. "Provisioning, Autodiscovery and
Signaling in L2VPNs", draft-ietf-l2vpn-signaling-08.txt,
May 2006 ( work in progress )
Author's Addresses
Florin Balus
Alcatel-Lucent
701 E. Middlefield Road
Mountain View, CA, USA 94043
Email: florin.balus@alcatel-lucent.com
Mustapha Aissaoui
Alcatel-Lucent
600 March Road
Kanata, ON
Canada
e-mail: mustapha.aissaoui@alcatel-lucent.com
Balus, et al. Expires January 8, 2008 [Page 13]
Internet-Draft VPLS Extensions for PBB July 2007
Matthew Bocci
Alcatel-Lucent,
Voyager Place
Shoppenhangers Road
Maidenhead
Berks, UK
e-mail: matthew.bocci@alcatel-lucent.co.uk
John Hoffmans
KPN
Regulusweg 1
2516 AC Den Haag
Nederland
Email: john.hoffmans@kpn.com
Geraldine Calvignac
France Telecom
2, avenue Pierre-Marzin
22307 Lannion Cedex
France
Email: geraldine.calvignac@orange-ftgroup.com
Raymond Zhang
BT
2160 E. Grand Ave.
El Segundo, CA 900245 USA
EMail: raymond.zhang@bt.com
Nabil Bitar
Verizon
40 Sylvan Road
Waltham, MA 02145
e-mail: nabil.bitar@verizon.com
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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
Balus, et al. Expires January 8, 2008 [Page 14]
Internet-Draft VPLS Extensions for PBB July 2007
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 Statement
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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Balus, et al. Expires January 8, 2008 [Page 15]