Internet DRAFT - draft-andersson-gels-bof-prep
draft-andersson-gels-bof-prep
Network Working Group L. Andersson
Internet-Draft Acreo AB
Expires: April 24, 2006 D. Papadimitriou
Alcatel
October 21, 2005
Use of the Gnerealized Multi-Protocol Label Switching control plane for
point-to-point Ethernet Label Switching
draft-andersson-gels-bof-prep-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/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 24, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document proposes starting a work within the IETF to apply the
Generalized Multi-Protocol Label Switching (GMPLS) control plane to
Ethernet Label Switching and to make extensions to the GMPLS control
plane protocols as necessary for this application. This will be done
based on the protocols developed by the MPLS and CCAMP working groups
in the IETF. Ethernet Label Switching will use the data plane
Andersson & Papadimitriou Expires April 24, 2006 [Page 1]
Internet-Draft Ethernet Label Switching October 2005
encodings as specified by the IEEE 802 standards.
This document intends to gather the information necessary to have a
"GMPLS Ethernet Label Switching" BoF in Vancouver.
Conventions used in this document
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 [RFC2119].
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Objectives and scope . . . . . . . . . . . . . . . . . . . . . 6
2.1. Objectives . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3. Out of Scope . . . . . . . . . . . . . . . . . . . . . . . 7
3. Description . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Core Ethernet . . . . . . . . . . . . . . . . . . . . . . 9
3.3. Ethernet transport . . . . . . . . . . . . . . . . . . . . 9
3.4. Ethernet Label Switching Concepts . . . . . . . . . . . . 10
3.4.1. Modeling concepts . . . . . . . . . . . . . . . . . . 10
3.4.2. Deployment concepts . . . . . . . . . . . . . . . . . 10
3.4.3. Packets and Frames . . . . . . . . . . . . . . . . . . 11
3.4.4. Ethernet Labels . . . . . . . . . . . . . . . . . . . 11
3.4.5. IEEE 802.1Q terminology . . . . . . . . . . . . . . . 14
3.5. Related work in IETF . . . . . . . . . . . . . . . . . . . 15
3.5.1. RFC 3032 (MPLS over Ethernet) . . . . . . . . . . . . 15
3.5.2. RFC 3916 (Ethernet over Pseudo-Wire (PW)) . . . . . . 16
3.5.3. TRILL Approach . . . . . . . . . . . . . . . . . . . . 16
3.5.4. Positioning of Ethernet Label Switching . . . . . . . 17
4. General requirements . . . . . . . . . . . . . . . . . . . . . 19
5. Data plane . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.1. Data plane requirements . . . . . . . . . . . . . . . . . 20
5.2. Relationship to IEEE 802 . . . . . . . . . . . . . . . . . 20
6. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 22
6.1. Control Plane requirements . . . . . . . . . . . . . . . . 22
6.1.1. Link management requirments . . . . . . . . . . . . . 22
6.1.2. Routing requirements . . . . . . . . . . . . . . . . . 22
6.1.3. Signalling requirements . . . . . . . . . . . . . . . 22
6.1.4. Control channel requirements . . . . . . . . . . . . . 22
6.2. Cooperation with CCAMP WG . . . . . . . . . . . . . . . . 22
6.3. Cooperation with other Working Groups . . . . . . . . . . 23
6.3.1. Common review . . . . . . . . . . . . . . . . . . . . 23
6.3.2. Working groups . . . . . . . . . . . . . . . . . . . . 23
Andersson & Papadimitriou Expires April 24, 2006 [Page 2]
Internet-Draft Ethernet Label Switching October 2005
6.3.3. Potential overlap with other working groups . . . . . 23
7. Expected outcome . . . . . . . . . . . . . . . . . . . . . . . 24
7.1. Milestones . . . . . . . . . . . . . . . . . . . . . . . . 24
7.2. Documents . . . . . . . . . . . . . . . . . . . . . . . . 24
7.2.1. Framework . . . . . . . . . . . . . . . . . . . . . . 25
7.2.2. Routing Extensions . . . . . . . . . . . . . . . . . . 25
7.2.3. Signaling Extensions . . . . . . . . . . . . . . . . . 25
7.2.4. Routing Applicability . . . . . . . . . . . . . . . . 25
7.2.5. Signaling Applicability . . . . . . . . . . . . . . . 25
7.2.6. OAM features . . . . . . . . . . . . . . . . . . . . . 25
7.2.7. Ethernet Label switching MIB . . . . . . . . . . . . . 25
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
9. Security Considerations . . . . . . . . . . . . . . . . . . . 27
9.1. Attacks on the Data Plane . . . . . . . . . . . . . . . . 27
9.2. Attacks on the Control Plane . . . . . . . . . . . . . . . 27
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
11.1. Normative References . . . . . . . . . . . . . . . . . . . 29
11.2. Informative References . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
Intellectual Property and Copyright Statements . . . . . . . . . . 32
Andersson & Papadimitriou Expires April 24, 2006 [Page 3]
Internet-Draft Ethernet Label Switching October 2005
1. Introduction
This document proposes that the IETF undertakes a work to extend the
existing protocols that constitute the Generalized Multi-Protocol
Label Switching (GMPLS) control plane in such a way that this control
plane may be used for Ethernet Label Switching.
It also proposes that the extension of the GMPLS control plane SHALL
be done is such a way that it is possible to create a multi-layer
network dynamically controlled by a common control plane. For the
scope of this document at least one of the layer must be Ethernet,
but a there is nothing that precludes that the same approach is used
in non-Ethernet networks.
The information collected in this document is intended for an
"Ethernet Label Switching" BoF in Vancouver at the 64th IETF. During
this BOF we seek consensus for one of two alternatives:
1. that a new working group is started to undertake the work
described here
or
2. that the work we describe here is allocated to an existing
working group
The MPLS and CCAMP working groups have defined the use of MPLS and
GMPLS protocols for control of several L2 technologies, e.g. ATM and
FR, and for circuit-oriented technologies such as SONET/SDH. This
has been done by extending the IETF signaling protocols e.g. RSVP-TE
and routing protocols e.g. OSPF and IS-IS while their respective
data plane has been left unchanged (see e.g. RFC 3946 [RFC3946]).
The same approach will be used when extending the GMPLS control plane
for Ethernet Label Switching.
However, the choice of how to specify an Ethernet label is not as
straightforward as for other L2 technologies. There is no designated
VPI/VCI information field as in ATM or a DLCI information field as in
Frame Relay that we can use. There are however several options that
can be considered and need to be compared before taking a decision,
e.g. the Q-tag as specified in IEEE 802.1Q, the I-tag that currently
is specified in IEEE 802.1ah or if we should go for a new "G-tag"
("GMPLS-tag") especially allocated for Ethernet Label Switching.
This is further discussed in Section 3.4.4.
Control of Ethernet networks by the control plane technologies as
specified in GMPLS RFCs has been within the scope of the CCAMP
working group since the start, at least to the extent that Ethernet
Andersson & Papadimitriou Expires April 24, 2006 [Page 4]
Internet-Draft Ethernet Label Switching October 2005
is used in transport and core networks (see Section 1.2 of
[RFC3945]). Part of this discussion was captured in
[I-D.papadimitriou-ccamp-gmpls-ethernet-framework]. The work
proposed in this document could be viewed both as a consolitdation
and a continuation of the work started in [I-D.papadimitriou-ccamp-
gmpls-ethernet-framework].
Andersson & Papadimitriou Expires April 24, 2006 [Page 5]
Internet-Draft Ethernet Label Switching October 2005
2. Objectives and scope
This section outlines the objectives and scope of the proposed work
on Ethernet Label Switching. A set of high level requirements are
detailed in Section 4, Section 5.1 and Section 6.1.
2.1. Objectives
The objectives for the proposed work are listed below. The list is
not intended to be exhaustive, but to catch the major objectives.
o The key objective of the proposed work is to enable control of
point-to-point connectivity through Ethernet networks by the GMPLS
control plane as standardized by the IETF. The standards are
based on the work done in the CCAMP working group.
o It is an objective of the proposed work to contribute to the goal
of making it possible to configure and operate multi-layer
networks (MLNs). This type of network is called multi-region
network (MRN) in [I-D.shiomoto-ccamp-gmpls-mrn-requirements] and
[I-D.papadimitriou-ccamp-gmpls-mrn-extensions].
o It is an objective of the work to build on the work done by other
working groups within the IETF, in particular, the CCAMP WG.
o It is an objective of the proposed work to enable constraint based
routing and explicit routing.
o It is an objective of the work to build on the work done by other
Standards Developing Organizations (SDO), in particular the IEEE
802.
o It is an objective of the proposed work to use the structure of
the existing encoding of the Ethernet framing, number of bits and
size of fields are left unchanged, though the coding of Ethernet
label may add new semantics to one or more fields.
o It is an objective of the proposed work to achieve
interoperabilitiy with legacy Ethernet switches
o It is an objective of the proposed work to retain the legacy
functionality, e.g. VLANs of Ethernet switches
o It is an objective of the proposed work that switches that are
GMPLS Ethernet enabled support unlabeled frames
Andersson & Papadimitriou Expires April 24, 2006 [Page 6]
Internet-Draft Ethernet Label Switching October 2005
2.2. Scope
o The scope of the proposed work includes point-to-point (P2P)
Ethernet LSPs.
o Traffic engineered P2P Ethernet LSPs are within scope for the
proposed work.
o The scope of the proposed work includes setting up, removing,
managing and operating Ethernet LSPs in core and transport
networks.
o Defining format and value space for Ethernet labels (see
Section 7.2) are within scope for the proposed work. Support for
more than one label format is discussed in Section 3.4.4
2.3. Out of Scope
o GMPLS Ethernet LSPs to the customer premises and/or to hosts are
out of scope for the proposed work.
o GMPLS Ethernet Label Switching in access networks is out of scope
for the proposed work.
o GMPLS Ethernet Label Switching in campus networks is out of scope
for the proposed work.
o GMPLS Ethernet Label Switching in mobile and wireless networks is
out of scope for the proposed work.
o Multicast and point-to-multipoint LSPs, both Traffic Engineered
and non-Traffic Engineered are out of scope for the proposed work.
o Changes to the Ethernet data plane are not planned within the
proposed work. To the extent such changes are necessary they need
to be achieved through the mechanisms and methods defined by the
IEEE.
Andersson & Papadimitriou Expires April 24, 2006 [Page 7]
Internet-Draft Ethernet Label Switching October 2005
3. Description
This section includes a brief description of the positioning of
Ethernet Label Switching, and its relationship with respect to MPLS
and GMPLS.
The original MPLS architecture (defined in RFC 3031 [rfc3031] and RFC
3032 [rfc3032]) has been extended in RFC 3945 [rfc3945] to include
LSRs whose forwarding plane recognizes neither packet, nor cell
boundaries, and therefore, cannot forward data based on the
information carried in either packet, or cell headers. Specifically,
such LSRs include devices where the switching decision is based on
the L2 frame header. Interfaces on these LSRs recognize frame
boundaries (i.e. frame delimitation) and can switch data based on the
content of the MAC frame header. Such interfaces are referred to as
Layer-2 Switch Capable (L2SC) interfaces.
The Ethernet MAC frame header includes the EtherType, the different
TAGs, and the MAC_DA/SA addresses. In this context, a GMPLS Ethernet
labeled frame is defined as an Ethernet MAC frame whose header
encodes the label value. Per the GMPLS architecture, a label's
interpretation depends on the type of the link over which the label
is used. Therefore, GMPLS Ethernet switches need be able to
correctly handle all types of Ethernet MAC frames, including the
GMPLS labeled frames, to ensure inter-working with 802.1 bridges. An
extensive description of label distribution concepts are found in RFC
3036 [rfc3036]. Ethernetlabel assignment , following the GMPLS
choicie of signalling protocols RFC 3473 [rfc3473], mandates a
downstream-on-demand label allocation and distribution, with ingress
initiated ordered control, see RFC 3945 [rfc3945].
3.1. Scenarios
In the CCAMP working a design team was chartered to look into
different Ethernet GMPLS scenarios. In the report from the design
team [I-D.papadimitriou-ccamp-gmpls-ethernet-framework] four
different scenarios were discussed. The four different scenarios
addressed the problem space from very separate starting points.
While the discussion in this section of what is in and out of scope,
stricly only applies to the CCAMP working group charter, we have not
indications that the scope will radically change even if we were to
take the work to another working group. It is therefore assumed that
what is within scope for the CCAMP working group is also within scope
for any working group working on GMPLS controlled Ethernet, and vice
versa.
Scenario 1, GMPLS for access and aggregation networks, were
Andersson & Papadimitriou Expires April 24, 2006 [Page 8]
Internet-Draft Ethernet Label Switching October 2005
considered to be out of scope. The reason for this is that the scope
of the present any work on Ethernet Label Switching needs to follows
the guidelines in the CCAMP working group charter i.e. "The CCAMP
working group coordinates the work within the IETF defining a common
control plane and a separate common measurement plane for physical
path and core tunneling technologies of Internet and telecom service
providers (ISPs and SPs), e.g. O-O and O-E-O optical switches, ATM
and Frame Relay switches, MPLS, GRE, in cooperation with the MPLS
WG."
It is not that given access and aggregation networks are are
environments where GMPLS controlled label swtiching is suitable. An
assessment of GMPLS applicability in access and aggregation networks
should be the first step. Once we have this assessment , given that
it is positive, a decision if this something IETF wants to undertake
could be taken. It is however not within scope for the proposed
work.
Scenario 2, GMPLS for Metro and Metro Core networks are within scope,
but the scenario as described focused on use of the VLAN-id as
Ethernet label. For a number of reasons this were considered
creating a solution before we've addressed the requirements.
The solution proposed in scenario 2 should be revisisted when a
solution is discussed, to assess if it is possible and beneficial to
use, partly use or accomodate the solution proposed for Metro and
Metro core networks in the approach discussed in this document.
Scenario 3 and 4 are similar the difference lies more in
applicability than requirements. Scenario 3 addresses the case where
a common control plane is used for all dynamically controlled network
layers, while scenario 4 addresses transport networks only. Scenario
4 might be considered a subset of scenario 3, while scenario 2 could
be considered a subset of both or either of scenario 3 and 4.
3.2. Core Ethernet
Ethernet Label Switching for core Ethernet aligns closely with
scenario 3 as it was describe in the report from the design team
[I-D.papadimitriou-ccamp-gmpls-ethernet-framework], i.e. the model
with a common control plane (common routing and signaling protocols)
for IP (packet), Ethernet (frame) and optical parts of a network.
3.3. Ethernet transport
The Ethernet Label Switching for Transport networks aligns closely
with scenario 4 as it was describe in the report from the design team
[I-D.papadimitriou-ccamp-gmpls-ethernet-framework]. This model is
Andersson & Papadimitriou Expires April 24, 2006 [Page 9]
Internet-Draft Ethernet Label Switching October 2005
limited to scenarios where the Ethernet LSP is carried over circuits
(e.g. SDH/Sonet).
3.4. Ethernet Label Switching Concepts
3.4.1. Modeling concepts
When modeling an MPLS network, we talk about two different types of
nodes, a Label Edge Router (LER) and a Label Switching Router (LSR)
and the links between them. In GMPLS controlled Ethernet networks we
might talk about Ethernet LERs and Ethernet LSRs.
o Ethernet LER - an Ethernet LER is a function that can take an
incoming Ethernet frame and add or remove the Ethernet label.
o Ethernet LSR - an Ethernet LSR is a function that can take an
incoming labeled Ethernet frame and swap the Ethernet label.
A more comprehensive MPLS terminology is found in RFC 3031 [rfc3031].
3.4.2. Deployment concepts
In actual deployments the LER and LSR concepts is not that useful.
This is because both function could very well be co-located in the
same "box".
o A switch could take an incoming un-labeled packet and switch to an
interface that is not labeled controlled, i.e. "normal" Ethernet
switching.
o The switch could also take the incoming frame from a non-labeled
controlled interface (or an Ethernet frame that originates within
the switch) and switch it to a labeled controlled interface while
adding the Ethernet label, i.e. the LER function.
o The switch could also take the incoming frame from a labeled
controlled interface and switch it to a non-labeled controlled
interface while removing the Ethernet label, i.e. the LER
function. It is concievable that the non-label control interface
is an internal interface within the switch and that the frame is
destined to the switch.
o The switch could also take the incoming frame from a labeled
controlled interface and switch it to a labeled controlled
interface while swapping the Ethernet label, i.e. the LSR
function.
In a deployment an LSP originates on an ingress LSR and terminates on
Andersson & Papadimitriou Expires April 24, 2006 [Page 10]
Internet-Draft Ethernet Label Switching October 2005
a egress LSR, for point-to-point bi-directional LSPs the same pair
LSRs acts both as ingress and egress LSRs.
3.4.3. Packets and Frames
Multi-layer GMPLS potentially crosses the border between the IP layer
and the Ethernet layer. In both layer information encapsulated
(layer specific information added before and/or after the payload) is
carried from one node to another. In Ethernet we talk about such
entities as "frames" while they are called "packets" in the IP layer.
Ethernet Label Switching intends to use a label inserted in the
Ethernet encapsulation.
Note need to reformulate the last sentence!
3.4.4. Ethernet Labels
In this section some of the proposals on how to define an Ethernet
label are outlined and discussed. Some of the arguments for and
against, though it is unlikely that it is exhaustive list, are given.
It is too early to take a decision, but some alternatives has been
discussed at some length, e.g. in the L2SC design team and the CCAMP
working group.
The proposals listed here are possibly not the only proposals, but at
least they cover the main ideas that have been discussed. Two key
questions that is unresolved is the size of the of the label space,
and if we need a TTL or not (in a source initiated ordered label
control assignment using a loop detection mechanism such as the RRO a
is TTL normally not needed).
o use the MPLS shim header
This approach makes use of the shim header label as specified in
RFC 3032 [rfc3032]. The good thing is that this is proven to work
and since we are talking about Ethernet it is always possible to
introduce a new label stack between the L3 payload and the
Ethernet encapsulation. However this would require the Ethernet
switch to swap, push and pop labels as well as re-write source and
destination MAC-addresses at each hop.
When switching on the shim header this is strictly not GMPLS
controlled Ethernet Label Switching, it is the Label Switching as
it was defined for the packet part of the network. In this mode
of operation the Ethernet frame starts/terminates at each hop, and
the destination and source address is changed in each hop.
o use the Q-tag and switch on the VLAN ID
Andersson & Papadimitriou Expires April 24, 2006 [Page 11]
Internet-Draft Ethernet Label Switching October 2005
This approach has been discussed over some time. One argument
that have been put forward in favor of this approach is that VLAN
ID processing can be handled by "all" Ethernet switches. There
are two drawbacks that has been put forward: the label space is
relatively small (12 bits) and it makes it impossible to
simultaneously use normal VLAN IDs in GMPLS controlled Ethernet
Label Switching networks as the semantic of the VLAN ID is
modified.
From a conceptual point of view a VLAN ID is not something an
Ethernet switch takes a switching decision on, what happens is
rather that the domain over which the MAC-address learning is done
is limited (by definition, a VLAN delimits a broadcast domain). A
classical Ethernet switch performs MAC address learning using the
unknown unicast frame forwarding. When a frame with an Q-tag/VLAN
ID arrives to a switch over an interface with that VLAN configured
and the switch doesn't have the destination MAC-address cached,
that frame will be forwarded (flooded) over all interfaces with
that VLAN configured. When the switch sees traffic in the other
direction coming in over one of the interfaces over which the
traffic was flooded, the switch learns the combination of source
address and interface and places it in the MAC-address cache. As
long as the MAC-address remains in the MAC-address cache incoming
frame will be forwarded over a single interface only.
VLANid is not the switching criteria, but a limitation of the
switching domain. The implication is that enabling VLAN ID
switching would require disabling MAC learning and MAC_DA based
forwarding.
o use a proprietary MAC-address space
To create unique MAC-addresses the IEEE assigns three bytes OUIs
(Organizational Unit Identifier). This OUI can be used to create
unique MAC-addresses that can be assigned to equipment
manufactured by a vendor. The OUI is used as the first three
bytes of the six byte MAC-address.
The idea here is that IETF should apply for an OUI and use it to
indicate that the rest of the MAC-address is the Ethernet label.
The good thing about this proposal is that it leaves a
comparatively large space for the label value (three bytes). It
is even possible that the label space is large enough to make
"label swapping" necessary, if this is the case an estimate of the
n-squared problem and the amount of state in the switches.
On the negative side is that requires re-writing of source and
destination MAC-addresses once the frame enters/leaves the GMPLS
controlled Label Switching Ethernet network. If the destination
is only modified this leaves asymmetric encoding between the
MAC_SA and MAC_DA. It also changes completely processing of this
field compared to its current usage. Note also that this encoding
Andersson & Papadimitriou Expires April 24, 2006 [Page 12]
Internet-Draft Ethernet Label Switching October 2005
is not extensible since based on a fragmentation of an existing
information field.
There are number of issues that needs to be discussed with this
proposal, e.g. introperability with existing switches and with
switches that is both GMPLS and non-GMPLS controlled.
o use a new TPID (tag protocol identifier)
A Q-tag is structured the following way. The first two bytes is a
"tag protocol identifier" with the value 0x8100 that indicates a
(C-)VLAN tag in the next two bytes including 3 priority bits
(Priority Code-Points), a 1-bit Canonical Format Indicator and a
12-bit VLAN id.
The idea here is to apply for a new TPID, and use the 13 bits of
the last two bytes as a label and keep the 3 priority bits. The
label space would be 8192 labels. The strength with this
proposals is two-fold. First there is no change in semantic from
already existing and defined TAGs. Then, forwarding based on MAC-
address or re-writing is not necessary, on the other hand there
are certain effects on the Ethernet forwarding plane. Use of the
IEEE802.1 Q-tag will apply to IEEE802.1ad switches.
In this mode of operation the source and destination MAC-addresses
of the MAC frames remain unchanged over the entire length of the
Ethernet LSP, the same as for the Ethertype..
o use the I-tag that will be specified in IEEE802.1ah
There is currently not enough information available on this, but
it is certainly worth investigating since it will give us a label
space of 20 bits.
3.4.4.1. Label stack encoding
A label stack is defined as an ordered set of labels, this means that
for each of the proposed solution here above a "label stacking"
method could be defined:
o when using the Q-tag and switch on the VLAN ID: techniques for
nesting Q-tags ("Q-in-Q") will work for the Ethernet Labels make a
two-level label stacking possible
o when using the new TPID a similar method could be considered with
a larger flexibility in terms of number of levels
o when using MAC-address space a two level stack of labels could be
considered in analogy to the MAC-in-MAC approach currently under
development by the IEEE (802.1ah)
Andersson & Papadimitriou Expires April 24, 2006 [Page 13]
Internet-Draft Ethernet Label Switching October 2005
However, the need of several entries in the label stack is still an
open issue for GMPLS controlled Ethernet Label Switching. Also, the
number of aggregation levels such environment would have to support
(i.e. nesting) is also a related open discussion point.
3.4.5. IEEE 802.1Q terminology
Below the terminology related to IEEE 802.1Q is oulined, e.g. naming
of the different fields and sub-fields.
3.4.5.1. TAG Format
Oct: 1 2 3 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TPID | TCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
bit: 8 1 8 1 8 1 8 1
IEEE 802.1 Q-tag format
Figure 1
TPID (16 bits): TAG Protocol Identification
TCI (16 bits): TAG Control Information
3.4.5.2. C-VLAN TAG Control Information (TCI)
Oct: 1 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCP |C| VID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
bit: 8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1
C-VLAN TAG Control Information
Figure 2
PCP (3 bits): Priority Code Point conveying priority & drop
eligibility parameters
C (1 bit): Canonical Format Indicator (CFI)
VID (12 bits): VLAN Identifier
Andersson & Papadimitriou Expires April 24, 2006 [Page 14]
Internet-Draft Ethernet Label Switching October 2005
3.4.5.3. S-VLAN TAG Control Information (TCI)
Oct: 1 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCP |D| VID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
bit: 8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1
S-VLAN TAG Control Information
Figure 3
PCP (3 bits): Priority Code Point conveying priority & drop
eligibility parameters
D (1 bits): Drop Eligible Indicator (DEI) bit
VID (12 bits): VLAN Identitifer
3.5. Related work in IETF
GMPLS control of Ethernet switches (as described in this document) is
based on the Ethernet MAC frame header. The difference with other
approaches currently worked in the context of other IETF working
groups are briefly described in the following paragraphs.
3.5.1. RFC 3032 (MPLS over Ethernet)
The difference between GMPLS control of Ethernet switches (as
described in this document) and MPLS transport over Ethernet links as
described in [RFC3032] is that in the latter packets are labeled
using MPLS shim headers. Labeled packets are then encapsulated in
Ethernet frames and targeted at the next IP/MPLS LSR along the path
of the LSP. At the incoming LSR interface, the Ethernet header is
stripped and forwarding takes place based on the encapsulated MPLS
label. At each hop, forwarding operation of native L3 packets is
done using labels and consists in looking up an incoming label to
determine the outgoing label, encapsulation, port, and other data
handling information.
When the Ethernet header is stripped of it also implies that a new
Ethernet header has to be created to carry the packet between each
MPLS hop. It should also be noted that one hop on an MPLS LSP could
correspond to several hops through the Ethernet network.
Andersson & Papadimitriou Expires April 24, 2006 [Page 15]
Internet-Draft Ethernet Label Switching October 2005
3.5.2. RFC 3916 (Ethernet over Pseudo-Wire (PW))
In [RFC3916], Ethernet frames are encapsulated and transported over a
packet-switched network using PSN tunnels (e.g. IP or MPLS tunnels).
Therefore, the forwarding is based on packet headers.
In single segment PW, the PW label is used a mux/demux label and does
not enter into forwarding at intermediate LSRs through which the PSN
tunnel is established. For multi-segment PW, the PW label is
inserted at the PE originating the PW i.e. the source PE, and is
switched at each intermediate PE until it reaches the PE terminating
the MS-PW, i.e. the destination PE.
By definition, a PW starts and ends on a PE, comparatively the
Ethernet Label Switching solution is meant to run in soft-permanent
mode (i.e. between PEs) but also in a switched mode i.e. between CEs.
An Ethernet pseudowire is indistinguishable from a point-to-point
Ethernet link, the fact MPLS is one of the techniques that is used to
implement PWs is of no consequence for the work on GMPLS controlled
Ethernet Label Switching, the Ethernet PWs are listed for reference
purposes only.
3.5.3. TRILL Approach
The TRILL working group has been recently formed to address the
shortages of Ethernet networks using the spanning tree protocol. As
such, the TRILL WG is intended to deliver a solution to this problem
for "CAMPUS" networks (even if its scope could be larger) by defining
an "intermediate" technology between IP and Ethernet MAC layer to
circumvent the drawbacks of the latter (in particular wrt to 802.1d
and related).
A specific difference compared to the TRILL WG is that the latter has
been chartered to provide a solution without explicitly being able to
run on existing IP routers as a software upgrade. On the other hand,
it is expected that a GMPLS capable LSR (acting as Ethernet LER)
would be able to initiate/terminate Ethernet LSPs across an Ethernet
LSR network.
A further difference between TRILL, at least as it is currently
chartered, is that TRILL aims for shortest-path routing of frames
(connectionless) in multi-hop IEEE 802.1-compliant Ethernet networks
with arbitrary topologies while GMPLS controlled Ethernet Label
Switching aims for constraint based routing and explicit routing.
Andersson & Papadimitriou Expires April 24, 2006 [Page 16]
Internet-Draft Ethernet Label Switching October 2005
3.5.4. Positioning of Ethernet Label Switching
The positioning of the present approach compared to the approaches
detailed in the present section depicted in the following figure:
+--------------+ +---------------+ +---------------+
| Payload | | Payload | | Payload |
+--------------+ +---------------+ +---------------+
| Ethernet MAC | | MPLS Label | | TRILL header |
-------------- --------------- ---------------
| PW Label | | Ethernet MAC | | Ethernet MAC |
-------------- --------------- ---------------
| PSN Tunnel | | PHY | | PHY |
+--------------+ +---------------+ +---------------+
PW Approach MPLS Approach TRILL Approach
+---------------+
| Payload |
---------------
| Ethernet MAC |
---------------
| PHY |
+---------------+
ELS Approach
Ethernet Label Switching in context
Figure 4
Compared to other approaches, Ethernet Label Switching provides an
integrated label encoding as part of the Ethernet MAC frame header.
No introduction of additional switching layer or forwarding layer is
considered. Compared to the PW approach however, Ethernet label
switching is positioned as a tunneling technology. This observation
becomes even more important when considering Ethernet LSR interfacing
classical Ethernet environment i.e. in order to avoid supporting
complex interaction(s) between IEEE 802.1 protocols at Ethernet LERs
the latter are expected to behave transparently. This means that
Ethernet IEEE 802.1 control frames are processed as any other user
Andersson & Papadimitriou Expires April 24, 2006 [Page 17]
Internet-Draft Ethernet Label Switching October 2005
frame.
On the other hand, the Ethernet Label switching approach provides a
simple mean for extending the Ethernet data plane capabilities with
the "well accepted" carried functionalities such as automated
provisioning, traffic-engineering, QoS parameter signaling,
differentiated routing and re-routing. It has to be emphasized that
the major difference between the TRILL approach is that the data
plane functionality is only enhanced such as to provide a "label
switching" behavior, all other capabilities are inherited from the
use of the associated GMPLS control plane.
Another remarkable property of the Ethernet label switching is that
it is able to work in both Switched (i.e. equivalent to ATM SVC mode)
and Soft-permanent mode (i.e. equivalent to ATM SPVC mode). Compared
to the other approaches only the MPLS one is able to deliver a
similar behavior between routers (or more generally when the labeled
packets carry a L3 payload). All other approaches are meant to work
on SPVC mode only i.e. between PEs (or their equivalent). As such
the Ethernet label switching capability would be gradually deployable
by first considering SPVC network capability and further consider
extension of the GMPLS control plane deployment on CEs.
In brief, the Ethernet label switching approach can be seen as a way
to position Ethernet as a carrier-grade tunneling technology without
modifying the relationship with the carried payload or the layers
over which Ethernet payload can be transported.
Andersson & Papadimitriou Expires April 24, 2006 [Page 18]
Internet-Draft Ethernet Label Switching October 2005
4. General requirements
1. For Ethernet Label Switching it SHALL be possible to use traffic
engineering methods defined for MPLS and GMPLS.
2. For Ethernet Label Switching it SHALL be possible to use recovery
methods defined for MPLS and GMPLS.
3. GMPLS is based on the IP routing and addressing models, in part.
IPv4 and/or IPv6 addresses are used to identify L2SC interfaces.
As it is not viable to associate an IP address with each end of
each L2SC interface, GMPLS scalability enhancement to addressing
must be re-usable: unnumbered links and link bundling.
4. GMPLS control plane information exchange between adjacent
Ethernet LSRs and control plane information processing MUST be
independent of the control channel implementation.
5. Control plane resilience mechanisms defined for GMPLS control
plane (e.g. RSVP engine graceful restart) SHALL be re-usable for
Ethernet LSR
Andersson & Papadimitriou Expires April 24, 2006 [Page 19]
Internet-Draft Ethernet Label Switching October 2005
5. Data plane
Note: This section should include a discussion of the relevant
Ethernet standards, at least IEEE 802.1Q, 802.1p, 802.1ad and
802.1ah.
Note: It also should include a discussion of the any data plane
issues within scope.
5.1. Data plane requirements
1. In current IEEE 802.1Q networks it is possible to create Virtual
LANs, by adding a VLAN-id to the Ethernet frame. The effect of
the VLAN-id is that the scope of the broadcast domain will be
limited and broadcast frames will only be sent to a subset of the
hosts connected to the network. This functionality MUST remain
unchanged when the GMPLS control plane is introduced.
2. The Ethernet MAC frame structure must be left unchanged i.e.
composed by Ethernet MAC frame header; a Payload and an FCS. The
former must remain structured such as to include the MAC_DA,
MAC_SA one or more TAGs and the EtherType. Ethernet TAG must
still include a TPID (TAG Protocol ID) and a TCI (TAG Control
Information). 802.1Q and 802.1ad include as part of the former an
Ethertype value.
3. It is assumed that the current physical medium (known as Ethernet
PHY) over which Ethernet labeled frames could be transmitted are
left unchanged and be forward compatible with the 802.3
specifications.
4. The MAC address space, size (6 bytes), format and semantic are
left unchanged and must still support unicast, multicast and
broadcast format and semantic.
5. The proposed Ethernet label format and switching must be such as
to leave IEEE 802.1ag CFM operations independent
6. MTU size: the size of the Ethernet labeled frame falls into the
revision of the IEEE P802.3as Ethernet Frame Expansion.
7. Note: Do we need to add further requirements?
5.2. Relationship to IEEE 802
The relationship between other SDOs and the IETF is managed by the
Internet Architecture Board (IAB). There is a long-standing liaison
relationship between the IETF and the IEEE 802. The proposed work
Andersson & Papadimitriou Expires April 24, 2006 [Page 20]
Internet-Draft Ethernet Label Switching October 2005
will leverage this relationship. However, it might be necessary to
form even closer cooperation in this area. We don't see that this
needs to take the form of establishing a new formal liaison
relationship between the two organizations, but could very well be
managed as part of the existing relationship.
Note: The IETF liaison to the IEEE is Bernard Aboba, and we will
bring the issues around the IETF/IEEE relationship and the proposed
work to him and discuss whether it is necessary to appoint further
people to work with the liaison relationship.
If and when the IETF undertake the proposed work, we will need to
coordinate closely with some of the IEEE 802.1 projects, especially
802.1ad and 802.1ah. The preliminary and informal contacts taken so
far are very promising.
Note: We had a very short discussion with Paul Condon (chairman of
the 802.1) and he indicated that the necessary channels are
available.
Note: IEEE liaison (suggested Bernard Adoba)
Andersson & Papadimitriou Expires April 24, 2006 [Page 21]
Internet-Draft Ethernet Label Switching October 2005
6. Control Plane
-
6.1. Control Plane requirements
Note: This section is for further study.
6.1.1. Link management requirments
Note: For further study
6.1.2. Routing requirements
Note: For further study
6.1.3. Signalling requirements
Note: For further study
6.1.4. Control channel requirements
Note: For further study
6.2. Cooperation with CCAMP WG
Note: Cooperation with CCAMP (suggested Kireeti and Adrian)
The IETF Common Control and Measurement Plane (CCAMP) working group
coordinates the work within the IETF for defining a common control
plane and a measurement plane for ISP and SP core tunneling
technologies. This includes, but is not limited to, defining
signaling protocols and measurement protocols such that they support
multiple physical path and tunnel technologies using input from
technology- specific working groups such as the MPLS working group;
protocol-independent metrics and parameters for describing links and
paths that can be carried in protocols.
The CCAMP Working group addresses, among others, a generalized
technology, referred to as GMPLS, where labels are defined in such a
way that they will be compatible with the technology they are
transported over. The CCAMP working group work focuses on common
methods across a broad spectrum of switching technologies. Base
GMPLS signaling (RFC 3471 [rfc3471] and RFC 3473 [rfc3473]) and
routing ([I-D.ietf-ccamp-gmpls-routing], and [I-D.ietf-ccamp-ospf-
gmpls-extensions]) are output of the CCAMP WG. [I-D.ietf-isis-gmpls-
extensions] is the product of the IS-IS Working Group. Documents
that propose extensions or changes to protocols that have been
Andersson & Papadimitriou Expires April 24, 2006 [Page 22]
Internet-Draft Ethernet Label Switching October 2005
specified by the CCAMP working group, e.g., documents that specify
new GMPLS methods or extensions and new GMPLS encapsulations MUST be
handled by the CCAMP working group.
One exception to this rule is when other IETF working group has been
appointed, with the prerequisite CCAMP WG agreement, to handle
extensions and/or changes to the protocols specified by the CCAMP
working group. The present work falls into this category. This
implies that any GMPLS protocol extension, or enhancement proposed in
the context of this item must be revisited by the by the CCAMP WG
such that the appropriate level of technical review is ensured. To
avoid extra delays and ensure right level of collaboration the review
process must be conducted earlier before WG Last Call process.
6.3. Cooperation with other Working Groups
6.3.1. Common review
Cooperation with other working groups, in particular protocol-
specific WG (e.g. IS-IS or OSPF) MUST involve the same review
process. This implies that any protocol extension, or enhancement
proposed in the context of this work item must be revisited by the
protocol-specific WGs such that the appropriate level of technical
review is ensured. To avoid extra delays and ensure right level of
collaboration the review process must be conducted earlier before WG
Last Call process.
6.3.2. Working groups
Cooperation is foreseen with the following Working Groups (in
addition to the CCAMP WG): OSPF WG, IS-IS WG, MPLS WG and TRILL WG.
Note: The specific list of working groups we need to co-ordinate and
co-operate with needs to be finalized.
6.3.3. Potential overlap with other working groups
Note: This section is for further study. Potentially the we that we
need to discuss the relationship with TRILL further.
Andersson & Papadimitriou Expires April 24, 2006 [Page 23]
Internet-Draft Ethernet Label Switching October 2005
7. Expected outcome
-
7.1. Milestones
Milestones are obviously related to progressing documents, we list
the set of documents we think is necessary for completion of the
proposed work see Section 3.4.4.
o milestone 0 - decision on the Ethernet label(s) format
o milestone 1 (possibly the Framework draft as working group
document Section 7.2.1)
o milestone 2 (possibly the Signaling and Routing Extensions drafts
as working ggroup documents Section 7.2.3 and Section 7.2.2)
o milestone 3 (possibly the Framework draft sent to the IESG to be
published as an informational RFC, Section 7.2.1).
o milestone 4 (possibly OAM features and MIB drafts as working group
document Section Section 7.2.6 and Section Section 7.2.7).
o milestone 5 (possibly the Signaling and Routing Applicability
drafts as wg documents Section Section 7.2.5 and Section
Section 7.2.4)
o milestone 6 (possibly the Signaling and Routing Extensions drafts
sent to IESG to be published as PS RFC)
o milestone 7 (possibly OAM features and MIB drafts sent to IESG to
be published as PS RFC)
o milestone 8 (possibly the Signaling and Routing Applicability
drafts sent to the IESG to be published as an informational RFC,)
Note: Dimitri is working on a first cut of the charter.
7.2. Documents
This section list documents that we believe should be included in the
output from the proposed work.
The documents are listed here tentatively, as the work progresses it
might turn out that we want to re-arrange the content between the
documents, merge or split documents.
Andersson & Papadimitriou Expires April 24, 2006 [Page 24]
Internet-Draft Ethernet Label Switching October 2005
7.2.1. Framework
Note: Framework (incl. data plane aspects)
The framework is intended to capture terminology, architechture and
requirements for GMPLS controlled Ethernet Label Switching. The
framework will also be the place where the format of the Ethernet
label(s) will be documented.
7.2.2. Routing Extensions
Note: Routing extensions
7.2.3. Signaling Extensions
Note: Signaling extensions
7.2.4. Routing Applicability
Note: Routing applicability
7.2.5. Signaling Applicability
Note: Signaling applicability
7.2.6. OAM features
Note: OAM features
7.2.7. Ethernet Label switching MIB
Note: Ethernet Label Switching MIB
Andersson & Papadimitriou Expires April 24, 2006 [Page 25]
Internet-Draft Ethernet Label Switching October 2005
8. IANA Considerations
Note: This section placed here tentatively.
Andersson & Papadimitriou Expires April 24, 2006 [Page 26]
Internet-Draft Ethernet Label Switching October 2005
9. Security Considerations
The BOF preparation document does not in itself add any new security
aspects to the Internet. However, below we list that reflects our
current understanding of the security aspects we would have to
consider if we were to undertake the proposed work.
The document raises similar security issues such as with any other
type of LSPs. However, additional security threats have been
identified:
o Possibility for the network to control the traffic injected by the
client in the data plane (BPDU, Multicast, Broadcasts, etc.)
o Entry points induced by the possible coexistence of the two
technologies (L2LSPs and usual Broadcast Ethernet mode)
9.1. Attacks on the Data Plane
Attacks on the data plane can be of the following form:
o modification of data traffic
o insertion of non-authentic data traffic
o Denial of Service (DoS) attacks
o traffic snooping
Introduction of GMPLS signaling fro Ethernet LSP MUST prevent these
attacks. Moreover, as an Ethernet LSP is by nature a point-to-point
tunnel, with a single entry point (head-end LSR) and exit point
(tail-end LSR). Policing (rate limit) and filtering is required only
on the head-end LSR.
9.2. Attacks on the Control Plane
GMPLS Ethernet networks will inherit the security issues of IP
networks similar to other GMPLS client networks, and the appropriate
trust models MUST be supported. Existing RSVP security mechanisms
RFC 2207 [RFC2207] and RFC 3097 [RFC3097] should also be analyzed/
evaluated in this context.
Andersson & Papadimitriou Expires April 24, 2006 [Page 27]
Internet-Draft Ethernet Label Switching October 2005
10. Acknowledgements
We would like to thank the CCAMP working group L2SC design team,
which joine3d the discussion on GMPLS controlled Ethernet Label
Switching with great enthusiasm.
We would also like to thanks Adrian Farrel for insightful major
technical comments and extensive nit-picking.
Andersson & Papadimitriou Expires April 24, 2006 [Page 28]
Internet-Draft Ethernet Label Switching October 2005
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
11.2. Informative References
[I-D.ietf-ccamp-gmpls-routing]
Kompella, K. and Y. Rekhter, "Routing Extensions in
Support of Generalized Multi-Protocol Label Switching",
draft-ietf-ccamp-gmpls-routing-09 (work in progress),
October 2003.
[I-D.ietf-ccamp-ospf-gmpls-extensions]
Kompella, K. and Y. Rekhter, "OSPF Extensions in Support
of Generalized Multi-Protocol Label Switching",
draft-ietf-ccamp-ospf-gmpls-extensions-12 (work in
progress), October 2003.
[I-D.ietf-isis-gmpls-extensions]
Kompella, K. and Y. Rekhter, "IS-IS Extensions in Support
of Generalized MPLS", draft-ietf-isis-gmpls-extensions-19
(work in progress), October 2003.
[I-D.papadimitriou-ccamp-gmpls-ethernet-framework]
Papadimitriou, D. and J. Choi, "A Framework for
Generalized MPLS (GMPLS) Ethernet",
draft-papadimitriou-ccamp-gmpls-ethernet-framework-00
(work in progress), July 2005.
[I-D.papadimitriou-ccamp-gmpls-mrn-extensions]
Papadimitriou, D., "Generalized Multi-Protocol Label
Switching (GMPLS) Protocol Extensions for Multi-Region
Networks (MRN)",
draft-papadimitriou-ccamp-gmpls-mrn-extensions-01 (work in
progress), February 2005.
[RFC2207] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC
Data Flows", RFC 2207, September 1997.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, January 2001.
Andersson & Papadimitriou Expires April 24, 2006 [Page 29]
Internet-Draft Ethernet Label Switching October 2005
[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and
B. Thomas, "LDP Specification", RFC 3036, January 2001.
[RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic
Authentication -- Updated Message Type Value", RFC 3097,
April 2001.
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Functional Description", RFC 3471,
January 2003.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3916] Xiao, X., McPherson, D., and P. Pate, "Requirements for
Pseudo-Wire Emulation Edge-to-Edge (PWE3)", RFC 3916,
September 2004.
[RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching
(GMPLS) Architecture", RFC 3945, October 2004.
[RFC3946] Mannie, E. and D. Papadimitriou, "Generalized Multi-
Protocol Label Switching (GMPLS) Extensions for
Synchronous Optical Network (SONET) and Synchronous
Digital Hierarchy (SDH) Control", RFC 3946, October 2004.
Andersson & Papadimitriou Expires April 24, 2006 [Page 30]
Internet-Draft Ethernet Label Switching October 2005
Authors' Addresses
Loa Andersson
Acreo AB
Email: loa@pi.se
Dimitri Papadimitriou
Alcatel
Email: dpapadimitriou@psg.com
Andersson & Papadimitriou Expires April 24, 2006 [Page 31]
Internet-Draft Ethernet Label Switching October 2005
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Andersson & Papadimitriou Expires April 24, 2006 [Page 32]
