Internet DRAFT - draft-jaihyung-ccamp-lse-architecture
draft-jaihyung-ccamp-lse-architecture
CCAMP Daegun Kim
Internet Draft Korea Telecom
Expires: April 2006 Jaihyung Cho
ETRI
October 2005
Label Switched Ethernet (LSE) Architecture
draft-jaihyung-ccamp-lse-architecture-00.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, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved.
J.Cho, et.al. Expires - April 2006 [Page 1]
Label Switched Ethernet Architecture April 2006
Abstract
A solution for GMPLS implementation over Ethernet based on label
encoding method using 48bits of Ethernet address is proposed.
Ethernet switches supporting this approach control L2-LSP using
source & destination MAC addresses. The format of GMPLS label
encoding on Ethernet header is described. GMPLS bridge model and
three implementation models over bridged core network are presented.
The purpose of this draft is not to define new bridge architecture
but to help understanding some aspects of this approach, and identify
requirements for potential extension to current GMPLS protocols and
bridge.
Table of Contents
1. Introduction...................................................2
2. Conventions used in this document..............................3
3. MAC Label Format...............................................3
4. GMPLS Bridge Models............................................5
4.1. Simple GMPLS Bridge Model................................ 5
4.2. Extended GMPLS Bridge Model.............................. 7
5. GMPLS Implementation Models....................................8
5.1. Straightforward GMPLS Implementation..................... 8
5.2. MAC Address Swapping..................................... 9
5.3. MAC-in-MAC Bridge Tunnel................................ 11
Security Considerations..........................................13
References.......................................................13
Author's Addresses...............................................13
1.
Introduction
GMPLS control over Ethernet as specified in GMPLS RFCs has been
identified within the scope of the CCAMP working group. Framework
architecture proposed in [FRA] presents some deployment scenarios and
requirements. However the framework does not include solution
involved in each scenario. Depending on the choice of solution, in
particular issues related in Ethernet label field, some scenario may
not feasible as other proposed scenarios.
Defining a label encoding method is an important issue because
performance of bridged GMPLS network, impact to legacy bridge design
may significantly be different according to the choice. Furthermore,
some approach seriously limits the scope of potential area of
application only within the core part of provider network that the
solution may not be suitable in full extent of Ethernet deployment.
Thus any proposed approach must be carefully examined in the aspect
J.Cho, et.al. Expires - April 2006 [Page 2]
Label Switched Ethernet Architecture April 2006
of potential extension to diverse Ethernet application before any
fundamental choice is made.
This document proposes a solution based on technology encoding GMPLS
label on 48bits of Ethernet address fields. Ethernet switches
supporting this approach control LSP using MAC addresses.
Implementation models on bridged network are presented in section 5.
The purpose of this document is to provide necessary information for
discussion on various implementation options and comparison between
them.
Some features proposed in this document may not exactly fit in
current scope of CCAMP working group. However it is included in this
document in order to help understanding potential area of application
and identifying requirements for acceptable extension in current
bridge architecture.
2.
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 [i].
3.
MAC Label Format
IEEE 802.1 Ethernet bridges forward frames based on 48bits of MAC
address, and additionally using VLAN tag [802.1Q]. When the GMPLS
implementation over Ethernet is considered based on current
deployment of bridge architecture, some feasible options to encode
layer-2 label in MAC header would be either using VLAN ID (12bit)
field or destination MAC address (48bit) and source MAC address
(48bit) fields.
Use of VLAN ID for label encoding may automate VLAN configuration
using IP protocols. However weaknesses are the size of VLAN ID is too
small (12bit=4096), and it may cause conflict with existing use of
VLAN if GMPLS modifies semantics of VLAN ID.
This document proposes MAC address fields for encoding of Ethernet
label. Figure 1 shows the format of Ethernet header that GMPLS labels
are encoded in the destination address and source address fields. In
current IEEE policy for MAC address allocation, IEEE is designated by
the ISO Council to act as the registration authority for the higher
three-octet of OUI number in the MAC address to be used by
manufacturer. Ethernet manufacturer may generate global unique MAC
address using the OUI prefix and address block of lower three-octet
J.Cho, et.al. Expires - April 2006 [Page 3]
Label Switched Ethernet Architecture April 2006
(24bit). The idea here is that GMPLS may use the lower three-octet
space exclusively if a unique OUI number is reserved for the protocol.
+-------+-------+-------+-------+-------+-------+
| 1byte | 2byte | 3byte | 4byte | 5byte | 6byte |
+-------+-------+-------+-------+-------+-------+
+-----------------------+-----------------------+
| OUI Prefix (=GMPLS) | DA-label (24bit) |
+-----------------------+-----------------------+
| OUI Prefix (=GMPLS) | SA-label (24bit) |
+---------------+-------+-----------------------+
| Length/Type | |
+---------------+ |
| |
| Payload |
| |
+-----------------------------------------------+
| FCS |
+-----------------------------------------------+
Figure 1. GMPLS Frame Format
With this labeling scheme, all Ethernet frames controlled by GMPLS
will have identical OUI number that they can easily be distinguished
from other Ethernet frames, if separate dataplane processing is
required. However this does not necessarily mean that separate
hardware is needed. Since the label structure and MAC address format
are identical, GMPLS labeled frames and Ethernet frames may share
common hardware part for table lookup and forwarding operation.
Another good point of this labeling scheme is that it allows
sufficient number of label space (2^24 = 16,777,216). Since the space
is far enough (even bigger than MPLS label) that in some scale of
network, the label can be used globally within the boundary of
network.
The other advantage is that GMPLS implemented bridges are perfectly
interoperable with legacy Ethernet bridges that GMPLS bridges may
function as normal Ethernet bridge, and at the same time, as label
switching node to GMPLS frames.
The GMPLS header shown in Figure 1 contains both DA-label and SA-
label. The SA-label indicates LSP of backward direction. The reason
for including backward label in the GMPLS header is to reduce
broadcast of unknown GMPLS frames in normal MAC learning bridges.
Legacy Ethernet bridges may exist between GMPLS bridges. When a GMPLS
frame is transmitted initially via the legacy bridges, legacy bridges
J.Cho, et.al. Expires - April 2006 [Page 4]
Label Switched Ethernet Architecture April 2006
broadcast the GMPLS frame as unknown Ethernet frame. The source
address (i.e. SA-label) is also learned by the bridges. When a GMPLS
frame is replied back along the same path, the legacy bridges do not
broadcast the frame because the destination address was learned
before. The bridges also learn the source address of the frame. As a
result, legacy bridges may learn the DA-label and SA-label after
initial exchange of GMPLS frames. Since GMPLS LSP is bi-directional,
this also facilitates correct learning of both labels in legacy
bridges. Another good point for enclosing bi-directional label is
that dataplane of intermediate GMPLS nodes may send error message
directly back to ingress node, without consulting control plane, if
something is wrong.
Note that the proposed label encoding method is transparent to the
use of Ethernet Length/Type field and VLAN tag. Network manager may
configure VLAN without regarding GMPLS deployment. GMPLS frames may
include VLAN tag if they follow the VLAN configuration, or they may
work independently to the VLAN policy. When the priority field of
VLAN tag is used, consistent TE policy can be imposed in both legacy
bridges and GMPLS bridges.
4.
GMPLS Bridge Models
4.1 Simple GMPLS Bridge Model
GMPLS can be implemented in different level of sophistication
according to service model provided by bridged GMPLS network. Figure
2 below shows the simplistic implementation model of GMPLS Bridge.
In this case, GMPLS control entity may co-exist with 802.1 bridge
control entities and bridge management entity. The underlying MAC
relay and E-ISS (Enhanced Internal Service Sub-layer) are as defined
in IEEE 802.1D and 802.1Q. The control plane entities configure
Filtering Database (i.e. MAC Table) and physical port state. 802.1
bridge control entities and GMPLS entity may share common Filtering
Database. MAC table entries of native Ethernet frames are learned in
dataplane, however MAC entries for GMPLS frames are configured by
GMPLS control entity. Native Ethernet frames are forwarded via active
ports which constitute spanning tree, however GMPLS frames may be
forwarded through non-disabled ports via shortest path established
using GMPLS protocols.
The IP box described in control plane denotes that IP forwarding
layer may use MAC service primitives when IP terminal or router
includes L2SC interface. This model is applicable to both edge node
and intermediate node in simple GMPLS forwarding model presented in
section 5.1.
J.Cho, et.al. Expires - April 2006 [Page 5]
Label Switched Ethernet Architecture April 2006
+-----------------------------------------+
| Bridge Control & IP Forwarding Layer |
| |
| +-------+ +-------+ +-------+ |
| | 802.1 | | GMPLS | | IP | |
| +-------+ +-------+ +-------+ |
| | MAC Table |
| v Setup |
+---+-----------+---------+-----------+---+
| | VLAN \ L2 / VLAN | |
| | Untagging \Relay/ Tagging | |
| +--------------+---+--------------+ |
| | | |
| MAC Dependant | | MAC Dependant |
+------------------+ +------------------+
|| ||
|| ||
-------------------+ +-------------------
LAN | | LAN
-------------------+ +-------------------
Figure 2. Simple GMPLS Bridge Architecture
4.2 Extended GMPLS Bridge Model
Figure 3 below shows an extended model of GMPLS bridge providing
sophisticated L2 service, such as label swapping and MAC-in-MAC
encapsulation. The model includes three internal sub-layers -
L2 - L2
Relay Sub-layer, G-Label Swapping Sub-layer, and Inner-MAC Relay Sub-
layer - in MAC relay subpart.
The L2 Relay Sub-layer (bottom level of MAC relay subpart in Figure
3) is as defined in IEEE 802.1D and 802.1Q. Native Ethernet frames
are relayed via this sub-layer and forwarded only through spanning
tree.
The G-Label Swapping Sub-layer (middle level of MAC relay subpart in
Figure 3) classifies GMPLS frames using first three octet of OUI
number. The layer may replace DA-label and SA-label of input frames
after label lookup operation. The L2 Relay Sub-layer and G-Label
Swapping Sub-layer may share common Filtering Database because MAC
address block for GMPLS frames is split from native Ethernet address
block. The GMPLS frames may be forwarded through any non-disabled
port via shortest path established using GMPLS protocols.
The Inner-MAC Relay Sub-layer (top level of MAC relay subpart in
Figure 3) encapsulate/decapsulate outer MAC header and forward frames
J.Cho, et.al. Expires - April 2006 [Page 6]
Label Switched Ethernet Architecture April 2006
according to inner MAC information. Only the MAC-in-MAC encapsulated
GMPLS frames are passed up to this layer. The outer MAC header is a
provider assigned GMPLS header and inner MAC header is usually a
customer assigned MAC header.
The extended bridge model presented here mainly applies to edge node
of which typical role in MPLS network is adaptation of user flows
into label switching domain. In the advanced forwarding models
explained in section 5.2 and 5.3, such role of LER (Label Switching
Edge Router) is performed in layer-2 bridge level.
Note that an edge bridge may not include all three sub-layers. For
example, when the MAC-in-MAC encapsulation is not required, the
Inner-MAC Relay Sub-layer is not necessary.
+-----------------------------------------+
| Bridge Control & IP Forwarding Layer |
| |
| +-------+ +-------+ +-------+ |
| | 802.1 | | GMPLS | | IP | |
| +-------+ +-------+ +-------+ |
| | MAC Table |
| v Setup |
+---+-----+---------------------+-----+---+
| | \ Inner-MAC / | |
| | (1) \ Relay / (2) | |
| +--------+---------------+--------+ |
| | G-Label \ G-Label / | |
| | Classify \ Swapping / | |
| +-----------+---------+-----------+ |
| | VLAN \ L2 / VLAN | |
| | Untagging \Relay/ Tagging | |
| +--------------+---+--------------+ |
| | | |
| MAC Dependant | | MAC Dependant |
+------------------+ +------------------+
|| ||
|| ||
-------------------+ +-------------------
LAN | | LAN
-------------------+ +-------------------
(1) MAC-in-MAC Decapsulation
(2) MAC-in-MAC Encapsulation
Figure 3. GMPLS Edge Bridge Architecture
J.Cho, et.al. Expires - April 2006 [Page 7]
Label Switched Ethernet Architecture April 2006
5.
GMPLS Implementation Models
5.1 Straightforward GMPLS Implementation
A straightforward implementation method of GMPLS over Ethernet
bridged core network, using the simple GMPLS bridge model as
described in Figure 2, is shown in Figure 4. The 'L2SC' boxes in the
figure denote bridge layer with the simple GMPLS implementation. The
ingress edge node (R1) in Figure 4 is assumed providing encapsulation
of service specific data unit into Ethernet payload, and transmission
of Ethernet frame across the core network. An example is IP router
encapsulating IP packet in Ethernet payload and transmitting to
egress IP router. The 'IP' box at egress edge node (R2) illustrates
that Ethernet header is striped off and the payload is forwarded
using service specific interface. Detail of the edge function in this
model is out of scope. GMPLS is responsible for distributing MAC
addresses (i.e. GMPLS labels) between GMPLS implemented nodes and
providing efficient and reliable Ethernet data path.
| |
| <........ Core Network ..........> |
| |
+------+ +------+
| IP | R1 S1 R2 | IP |
+------+ +------+ +------+
| L2SC | | L2SC | | L2SC |
+-+--+-+ +-+--+-+ +-+--+-+
| | L2-LSP | | L2-LSP | |
-------->| |==============>| |==============>| |------->
[Data][IP] [Data][IP][s1:d1] [Data][IP][s1:d1] [Data][IP]
Figure 4. GMPLS Controlled Bridge Network Model
The simple GMPLS bridge model presented in section 4.1 does not
change GMPLS label when the bridges relay frames. As a result, an
ingress/egress assigned GMPLS label must be configured constantly
along the path of L2-LSP. It is depicted in Figure 4 that egress (R2)
assigned DA-label (='d1') and ingress (R1) assigned SA-label (='s1')
are not changed at intermediate GMPLS bridge (S1). Therefore, the MAC
addresses (GMPLS labels) must be assigned globally within the
boundary of core network, and not exposed beyond the edge nodes. All
edge nodes of a bridged GMPLS network must share common pool of
available labels. This requires additional mechanism for coordinating
J.Cho, et.al. Expires - April 2006 [Page 8]
Label Switched Ethernet Architecture April 2006
label allocation of edges, or pre-allocation of label space for each
node. This weakness can be overcome when the simple bridge model is
enhanced with MAC address swapping capability presented in section
5.2.
This straightforward model utilizes Ethernet dataplane as defined in
IEEE 802.1D/Q. A clear advantage is that service providers are able
to build relatively low-cost network because Ethernet bridges are
cost-effective than sophisticated core routers. It is also noted that
GMPLS controlled Ethernet is able to provide better scalability,
reliability, path efficiency and traffic engineering than legacy
bridged network.
5.2 MAC Address Swapping
The problem of straightforward implementation of GMPLS without
modifying current bridge architecture is scalability, i.e. the need
for global coordination of label allocation. The solution for global
label allocation may not be obvious in large network, however
enhancement to legacy bridge architecture with address swapping
capability is relatively simple solution. Figure 5 below shows this
forwarding model of Ethernet label-swapping.
In Figure 5, DA-label and SA-label of GMPLS frames are changed at the
label-swapping bridges (S2, S3). There can be a number of non-label
swapping bridges, either 802.1 Ethernet or GMPLS implemented, between
the label-swapping bridges. The input labels and output labels are
allocated only by label-swapping capable bridges. Non-label swapping
bridges must configure the labels determined by the label-swapping
bridges.
S2 S3
+------+ +------+
| Swap | | Swap |
+-+--+-+ +-+--+-+
L2-LSP | | L2-LSP | | L2-LSP
=============>| |=============>| |===========>
[Data][s1:d1] [Data][s2:d2] [Data][s3:d3]
Figure 5. Label Swapped Frame Forwarding
Conceptually, the label-swapping bridges partition a bridged GMPLS
network according to label-space sharing unit. GMPLS label is
allocated locally at each partition surrounded by label-swapping
J.Cho, et.al. Expires - April 2006 [Page 9]
Label Switched Ethernet Architecture April 2006
bridges. As the size of partition smaller, label space
apportioned to each node become larger. For example in simple
implementation model of Figure 4, each GMPLS edge node may use 2^24/M
labels in average, where M is the number of edge nodes. When the
network is partitioned to N, the average label space available for
each node is increased to 2^24*N/M. If all bridges become label-
swapping capable (i.e. N=M), each node is free to use entire 2^24
label space, hence removes the need for global allocation of labels.
+----------------------------------+
| |
| +-------+ +-------+ +------+ |
| | 802.1 | | GMPLS | | IP | |
| +-------+ +-------+ +------+ |
| | MAC Table |
| v Setup |
+---+-----+---------------+----+---+
| | +--> \ G-Label /---+ | |
| | | \ Swapping / | | |
| +-|------+---------+-----|-+ |
| | | \ L2 / | | |
| | | +->\Relay/-+ | | |
| +-|-----|---+---+--|-----|-+ |
| | | | | | | |
| | | | | | | |
+-----|-----|---+ +--|-----|-----+
| | | |
| | | |
(L2-LSP)| | | | (L2-LSP)
---------+ | | +--------->
GMPLS Frames | | GMPLS Frames
| |
---------------+ +--------------->
Ethernet Frames (Spanning Tree)
Figure 6. Label Swapping Bridge Model
Figure 6 above shows a bridge model of label-swapping capability. The
bridge model includes G-Label Swapping Sub-layer. GMPLS frames are
classified using the unique OUI number and passed to the G-Label
Swapping Relay. The relay may replace DA-label and SA-label after MAC
table lookup operation. Other native Ethernet frames are relayed via
underlying L2 Relay. Note that this layering model only describes
conceptual separation of the two sub-layers, and there can be no
J.Cho, et.al. Expires - April 2006 [Page 10]
Label Switched Ethernet Architecture April 2006
physical distinction in actual implementation. The two sub-layers may
share common Filtering Database.
5.3 MAC-in-MAC Bridge Tunnel
The bridge model presented above is further extended in this section
in order to provide application service of L2-LSP, such as Layer-2
VPN [L2VPN]. Figure 7 below illustrates an Ethernet service model
providing transmission of user frame via L2-LSP tunnel. In the figure,
ingress edge bridge (S4) encapsulates user frame '[s1:d1]' into GMPLS
frame '[s2:d2]'. The encapsulated user frame is transmitted via MAC-
in-MAC tunnel. The GMPLS header is removed at the egress bridge (S5),
and the user frame is forwarded in bridge level.
| |
Customer ...> | <.... Provider ....> | <... Customer
Network A | Network | Network B
| |
+------+ S4 S5 +------+
|Encap.| |Decap.|
+-+--+-+ +-+--+-+
User L2 | | L2-LSP Tunnel | | User L2
------------->| |===================>| |------------>
[Data][s1:d1] [Data][s1:d1][s2:d2] [Data][s1:d1]
^ ^
| |
User MAC ---+ +--- Provider MAC
Figure 7. MAC-in-MAC Tunnel Service using L2-LSP
The enhanced bridge model of MAC-in-MAC encapsulation is described in
Figure 8. In Figure 8 below, the bridge model includes Inner-MAC
Relay Sub-layer on top of MAC relay subpart. Major function of this
sub-layer is decapsulating outer MAC header (i.e. GMPLS frame header)
and forward inner MAC frame (i.e. user frame) according to
information of inner Filtering Database. The output user frame of
this sub-layer is encapsulated in a GMPLS frame corresponding to
output L2-LSP tunnel. GMPLS protocol is responsible for controlling
the L2-LSP tunnel, and some entries in inner Filtering Database.
The input & output L2-LSP tunnels are viewed as virtual ports in
Inner-MAC Relay Sub-layer. The user frame given to Inner-MAC relay
J.Cho, et.al. Expires - April 2006 [Page 11]
Label Switched Ethernet Architecture April 2006
may either be VLAN tagged/untagged. An internal VLAN may also be
configured between the virtual ports. The behavior of Inner-MAC relay
may not exactly as defined in IEEE 802.1D/Q because default action of
inner MAC relay is not always broadcasting of unknown frame. This is
because there can be millions of virtual ports (i.e. L2-LSP tunnels)
in the sub-layer that broadcasting to all virtual ports is
unrealistic. However the Inner-MAC Relay may learn source MAC
addresses from user frames and optimize broadcasting.
+--------------------------------------+
| |
| +-------+ +-------+ +-------+ |
| | 802.1 | | GMPLS | | IP | |
| +-------+ +-------+ +-------+ |
| | MAC Table |
| v Setup |
+---+----+---------------------+---+---+
| | +->\ Inner-MAC /-+ | |
| | | \ Relay / | | |
| +-|:|---+---------------+--|:|-+ |
| | |:| \ G-Label / |:| | |
| | |:| \ Swapping / |:| | |
| +-|:|------+---------+-----|:|-+ |
| | |:| \ L2 / |:| | |
| | |:| \Relay/ |:| | |
| +-|:|---------+---+--------|:|-+ |
| |:| | | |:| |
| |:| | | |:| |
+-----|:|---------+ +--------|:|-----+
|:| |:|
|:| L2-LSP |:| L2-LSP
|:| Tunnel |:| Tunnel
| |
| |
-------+ +------>
User Frames User Frames
Figure 8. MAC-in-MAC Encapsulation Bridge Model
The L2-LSP tunnel described in user side may not actually exist if
the user is not L2SC capable. Users connected via native Ethernet
link may transmit/receive Ethernet frames with/without VLAN tag. In
this case, null L2-LSP tunnel associates internally per user VLAN or
per physical port. The Inner-MAC Relay treats null L2-LSP tunnels as
other virtual ports, however forwards frames without MAC-in-MAC
encapsulation in user side.
J.Cho, et.al. Expires - April 2006 [Page 12]
Label Switched Ethernet Architecture April 2006
Security Considerations
The Inner-MAC Relay Sub-layer must have some protection from user MAC
explosion. Configuration error in user network or malicious
manipulation of source MAC address may cause such explosion. Care
must be taken when control message is to be accepted from user frames
at the Inner-MAC Sub-layer. Treatment of user ping for L2 connection
or pause message are issues requiring some discussion.
References
[FRA] Papadimitriou, D. and Cho, J. "A Framework for
Generalized MPLS (GMPLS) Ethernet",
draft-papadimitriou-ccamp-gmpls-ethernet-framework-00
(work in progress), July 2005.
[802.1D] IEEE, "Media Access Control (MAC) Bridges",802.1D,
ANSI/IEEE Standard Document, 1998
[802.1Q] IEEE, "Virtual Bridged Local Area Network", 802.1Q,
ANSI/IEEE Standard Document, 2003
[L2VPN] Loa Andersson, Eric C. Rosen, "L2VPN Framework",
draft-ietf-l2vpn-l2-framework-05.txt, Jun. 2004
Author's Addresses
Daegun Kim(Korea Telecom)
Email: dkim@kt.co.kr
Jaihyung Cho (ETRI)
161 Gajung Dong,
Yuseong Gu, Daejeon, Korea
Phone: +82 42 860 5514
Email: jaihyung@chol.com
J.Cho, et.al. Expires - April 2006 [Page 13]
Label Switched Ethernet Architecture April 2006
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 (2004). 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.
Full Copyright Statement
Copyright (C) The Internet Society (2004). 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.
J.Cho, et.al. Expires - April 2006 [Page 14]
Label Switched Ethernet Architecture April 2006
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.
J.Cho, et.al. Expires - April 2006 [Page 15]
