Internet DRAFT - draft-jaihyung-lse-architecture
draft-jaihyung-lse-architecture
Dae Young Kim
Internet Draft CNU
Expires: July 2006 Jaihyung Cho
ETRI
January 2006
Label Switching Ethernet (LSE) Architecture
draft-jaihyung-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 (2006). All Rights Reserved.
J.Cho, et.al. Expires - July 2006 [Page 1]
Label Switching Ethernet Architecture July 2006
Abstract
A solution for GMPLS implementation using 48bits of Ethernet
multicast address as label is proposed. It is claimed that Ethernet
bridges supporting IEEE 802.1D-2004 and IEEE 802.1Q-2003 may
implement GMPLS according to this proposal without requiring
modification to data plane, hence this solution is an appropriate
candidate solution for GELS (GMPLS Ethernet Label Switching) group.
The LSP established in this method is intrinsically bi-directional.
Ethernet bridges of this implementation provide traffic engineered
frame delivery path. Any point-to-point LSP can be transformed to
multi-point LSP, and vice versa. It is interoperable with 802.1D/Q
bridges. This proposal allows automated setup of VLAN using GMPLS in
small scale network. IEEE 802.1 controlled spanning tree path may co-
exist with GMPLS controlled LSP path when VLAN is used for
segregating GMPLS flows and normal Ethernet flows. Clear advantage of
this proposal compared to all-router based backbone network is cost-
effectiveness that it helps reducing CAPEX/OPEX of operators. With
the aid of well-established IP technology, it also helps enhancing
scalability and manageability of bridged backbone network.
Table of Contents
1. Introduction...................................................3
2. Conventions used in this document..............................4
3. GMPLS Label Format.............................................4
4. GMPLS Bridge Model.............................................6
5. GMPLS Implementation Models....................................7
5.1. IP Service in Bridged Core Network....................... 8
5.2. Coexistence with Spanning Tree and Ethernet Service...... 9
5.3. MAC-in-MAC Tunnel Service............................... 9
5.4. Interoperation with GMPLS unaware bridges.............. 10
6. Inter-domain Extension and Future Work..................... 12
Security Considerations..........................................13
References.......................................................13
Author's Addresses...............................................14
J.Cho, et.al. Expires - July 2006 [Page 2]
Label Switching Ethernet Architecture July 2006
1.
Introduction
GMPLS control over Ethernet as specified in GMPLS RFCs has been
identified within the scope of the CCAMP working group. GELS (GMPLS
Ethernet Label Switching) group has been proposed in this initiative
to find best approach for GMPLS implementation over IEEE bridges. A
strong requirement raised in the group is that any potential proposal
must not assume modification of Ethernet data plane for this
implementation, other than currently defined or pledged to be
supported in IEEE.
This document is a revision to original proposal of LSE (Label
Switching Ethernet) architecture to meet the requirement. Main
objective of this solution is to configure 48bits of MAC addresses in
Filtering Database (FDB) using GMPLS in order to provide scalable TE
path. However, this proposal also doesn't preclude use of GMPLS for
configuring VLAN in limited scale of network. In order to achieve
this, this proposal utilizes Extended Filtering Service defined in
IEEE 802.1D-2004 [IEEE8021D], and Enhanced Internal Sublayer Service
(EISS) defined in 802.1Q-2003 [IEEE8021Q].
It is allowed in [IEEE8021D] that group forwarding entry (i.e.
Ethernet multicast address) can be configured either through
management control or using GMRP (GARP Multicast Registration
Protocol). In IEEE term, when multicast address is configured using
management primitives, it is called static filtering entry. If the
multicast address is configured by GMRP using control primitives, it
is called dynamic group registration entry. Both types of entries are
not subject to MAC learning or aging timer that once the address is
configured in FDB, the frame forwarding path is fixed unless the node
fails. Using this group forwarding behavior, GMPLS control entity may
configure point-to-point or multi-point LSP over 802.1D network.
Other useful feature defined in [IEEE8021D] is default filtering
behavior of unknown group address. When it is enabled, any reception
of unregistered multicast frames will be silently discarded. This
behavior is very useful in preventing looping or flooding of unknown
Ethernet frames. Note that Ethernet bridges usually broadcast data
frames via spanning tree when the destination address is unknown.
Since GMPLS may disable spanning tree or open all ports as forwarding
state in order to provide shortest path via any port, broadcasting
behavior of unknown frame may cause fatal result. However, when
multicast address is used in destination address field, this risk can
be reduced because bridges will discard unknown multicast frames.
Hence it is safer for GMPLS to control multicast Ethernet frames
rather than unicast Ethernet frames. Further, [IEEE8021D] defines
several useful tools for controlling multicast traffic, such as
selective permission or blocking of group addresses, that it will
J.Cho, et.al. Expires - July 2006 [Page 3]
Label Switching Ethernet Architecture July 2006
facilitate future extension of GMPLS implementation to multi-point
Ethernet service.
The other good reason to use multicast address for GMPLS label is
that point-to-point LSP may seamlessly be converted to multi-point
LSP or vice versa, because the LSP is inherently a multicast
forwarding path. It only requires some port map manipulation of the
group forwarding entry in FDB to transform point-to-point path to
multipoint path.
For these reasons, this proposal utilizes group forwarding behavior
of Extended Filtering Service defined in IEEE 802.1D-2004 edition for
GMPLS implementation.
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.
GMPLS Label Format
Figure 1 below shows the proposed format of Ethernet multicast
address when GMPLS label is encoded. According to IEEE 802 standard
[IEEE802], 48bits of LAN MAC address consists of upper 24bits of OUI
(Organizationally Unique Identifiers) field and lower 24bits of
remaining part. IEEE allows individual organization generating LAN
MAC address using lower 24 bits of address block when unique OUI code
is obtained from IEEE. This allows exclusive use of approximately 16
million addresses for each organization.
Using the addressing scheme, GMPLS may secure 24bits size of label
space when an OUI number is reserved from IEEE for this protocol.
This allows approximately 16 million LSPs established per
administrative domain when the label is used globally in an intra-
domain. When several more OUI numbers are reserved for GMPLS, the
size of label space doubles. All Ethernet frames controlled by GMPLS
will have identical OUI number that they can easily be classified
from other Ethernet frames.
In order to apply default group filtering behavior to GMPLS frames,
this proposal recommends use of group prefixed OUI number for GMPLS.
In IEEE address format [IEEE802], the last bit setting of the first
octet in OUI number indicates that the address type is group
multicast.
J.Cho, et.al. Expires - July 2006 [Page 4]
Label Switching Ethernet Architecture July 2006
+-------+-------+-------+-------+-------+-------+
| 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
The GMPLS frame header shown in Figure 1 contains two group addresses,
DA-label and SA-label. The DA-label is used for forwarding the frame,
and the SA-label indicates LSP of backward direction. Since GMPLS
supports bi-directional LSP [RFC3945], this proposal recommends
inclusion of backward label in all frame header. It also aligns with
semantics of Ethernet header. In future extension, the information of
backward LSP may be used for sending OAM message back to ingress node
when corresponding data plane entity for OAM is developed in IEEE.
Use of Ethertype code or VLAN tag is orthogonal in this proposal.
However when VLAN tag is attached to GMPLS prefixed frames, GMPLS
controlled traffic can be separate from normal Ethernet traffic in
underlying port level. This allows IEEE 802.1 spanning tree path
coexists with GMPLS controlled LSP path as long as VLAN number is
distinguished. This means GMPLS control entity may coexist with
IEEE 802.1 control entities in control plane that bridges may provide
connection oriented service using LSP, as well as connectionless
service using IEEE spanning tree path. It is also noted that QoS
policy can be enforced in granularity of LSP when priority tag is
attached to GMPLS frames.
J.Cho, et.al. Expires - July 2006 [Page 5]
Label Switching Ethernet Architecture July 2006
4.
GMPLS Bridge Model
Figure 2 below shows a bridge model of GMPLS implementation when
802.1D/Q bridge is assumed. However, this proposal doesn't restrict
the underlying hardware model that other types of data plane switch,
such as IEEE 802.1ah, may also be applied.
In this bridge model, GMPLS control entity can be colocated with 802.1
bridge control entities and bridge management entity. The underlying
data plane switch provides necessary service primitives for
configuring Filtering Database (FDB) and port state. 802.1 bridge
control entities and GMPLS control entity may share resources in data
plane, or GMPLS may disable 802.1 control and exclusively use the
resources.
When GMPLS exclusively controls bridge, all bridge ports must be open
in forwarding state except administratively disabled port. As a
result, IP routing protocol in control plane advertises all available
links, and LSP can be established through any optimum port. Care must
be taken that no unicast frame infiltrate into the network, because
it may cause infinite duplication and flooding of the unknown frame.
Only the group prefixed GMPLS frames must flow in the network. All
GMPLS implemented bridges must set default group filtering behavior,
thus any reception of unregistered multicast frame must be discarded.
When GMPLS coexists with 802.1 bridge control entities, a VLAN ID
must be allocated for GMPLS in order to separate GMPLS traffic from
spanning tree traffic. Forwarding state of the VLAN chosen for GMPLS
must be configured in all ports except administratively disabled port.
Default group filtering behavior of the VLAN tagged frames should
also be configured. Only the VLAN tagged multicast frames should be
admitted for GMPLS service. Other VLANs can be used according to IEEE
802.1 protocols. Both types of multicast/unicast frames are allowed
in such VLAN.
J.Cho, et.al. Expires - July 2006 [Page 6]
Label Switched Ethernet Architecture July 2006
+-----------------------------------------+
| Bridge Control & IP Forwarding Layer |
| |
| +-------+ +-------+ +-------+ |
| | 802.1 | | GMPLS | |Routing| |
| +-------+ +-------+ +-------+ |
| | FDB & Port |
| v Setup |
+---+-----------+---------+-----------+---+
| | \ L2 / | |
| | EISS(VLAN) \Relay/ EISS(VLAN) | |
| +--------------+---+--------------+ |
| | | |
| MAC Dependant | | MAC Dependant |
+------------------+ +------------------+
|| ||
|| ||
-------------------+ +-------------------
LAN | | LAN
-------------------+ +-------------------
Figure 2. GMPLS Bridge Architecture
5. GMPLS Implementation Models
5.1 IP Service in Bridged Core Network
Figure 3 below illustrates an IP service model where core nodes
consist of homogeneous 802.1D/Q bridges. It is assumed the edge
routers (R1 and R2) provide IP service to external users, and the
Ethernet interfaces facing backbone are capable of promiscuous
reception of multicast Ethernet frames. GMPLS control entities exist
in both edge routers and core bridges, and distribute label
information (i.e. multicast MAC addresses) between them.
The edge routers and core bridges share common pool of label space
(i.e. multicast address block reserved for GMPLS) in the
administrative domain. In other words, a multicast address assigned
for an LSP is used globally in the intra-domain that once it is
occupied by an edge node, no other nodes in the network may use the
number until the edge node releases the number. This requires global
coordination of label allocation. There can be several methods for
global control of label use, such as dividing the 16 million
multicast addresses and pre-allocating to each edge node, or running
a centralized address allocation server. Detail of label allocation
scheme is beyond the scope of this document.
J.Cho, et.al. Expires - July 2006 [Page 7]
Label Switched Ethernet Architecture July 2006
| |
Edge Router | <........ Core Network ..........> | Edge Router
R1 | | R2
+------+ +------+
| IP | S1 | IP |
+------+ +------+ +------+
| L2SC | | L2SC | | L2SC |
+-+--+-+ +-+--+-+ +-+--+-+
| |(s1) L2-LSP | | L2-LSP (d1) | |
-------->| |==============>| |==============>| |------->
[Data][IP] [Data][IP][s1:d1] [Data][IP][s1:d1] [Data][IP]
Figure 3. GMPLS Controlled Bridge Network
An example for establishing a point-to-point multicast path (i.e.
unicast LSP in view of control plane) is explained using the figure 3.
In the figure, an egress edge router R2 allocates a multicast address
d1 (i.e. downstream label) for a FEC (Forwarding Equivalence Class).
A multicast reception state of the address d1 must be configured in
the interface of R2. The mapping information of the multicast address
and the FEC is distributed using RSVP-TE. Intermediate core bridge S1
reserves resources necessary for the LSP and configures multicast
forwarding entry of the address d1, hence establishes a multicast
path of R1->R2 direction. The ingress edge router R1 also allocates a
multicast address s1 for backward LSP and configures a multicast
reception state in the Ethernet interface. The upstream label s1 also
need to be distributed to S1 and R2, as a result, bi-directional
multicast path is established between R1 and R2. Detail of the
signaling procedure is out of the scope of this document.
When the ingress edge router R1 receives a data packet belong to the
FEC, R1 encapsulates the packet in an Ethernet frame of which
destination address is d1, and source address is s1. R1 forwards the
composed multicast frame via the established LSP, and the frame is
delivered to R2. Since R2 configured the multicast address d1 in the
input interface, R2 receives the frame and strips off the Ethernet
header and forwards the packet to the output interface. No label
swapping operation is necessary in intermediate nodes in intra-domain
application. It also does not require using VLAN when the service
model of the network is IP only.
J.Cho, et.al. Expires - July 2006 [Page 8]
Label Switched Ethernet Architecture July 2006
5.2 Coexistence with Spanning Tree and Ethernet Service
In this multi-service model, a bridged core network may provide both
IP service using edge routers, as well as Ethernet connectivity
service as specified in IEEE 802.1D/Q, when a VLAN is used for
separating edge router group from Ethernet servicing edges.
The edge router group that share common bridged core network must
transmit/receive frames tagged with the VLAN chosen for GMPLS.
Intermediate nodes must configure forwarding state of the VLAN in all
ports, as a result, LSPs can be established via any shortest path
available in the network. Filtering state of the VLAN must be
configured on the ports servicing external Ethernet user that no
unicast frame or bogus frame may infiltrate into the VLAN group.
Except the VLAN ID allocated for GMPLS, rest of 4093 VLANs can be
used for providing Ethernet access service in the bridged core
network. Those VLANs can be configured manually or using IEEE
protocols. This document doesn't preclude use of GMPLS for automated
setup of VLAN. When GMPLS is used for configuring VLAN, this may
reduce operational burden. However, a serious limitation of this
method is the size of VLAN ID (12bits) that it allows at most 4093
number of VLANs to be established in an administrative domain. This
is far short scale compared to 16 million label space available when
using MAC address for label.
While doubling the VLAN size as seen in IEEE 802.1ad may enhance the
scalability, it still has limitation of service-VLAN that maximum
number of customers supported in a provider domain is 4094 when
customer use of their own VLAN is to be supported [IEEE8021AD].
5.3 MAC-in-MAC Tunnel Service
For the scalability reason discussed in section 4.2, this document
supports use of MAC-in-MAC encapsulation tunnel for Ethernet service.
Edge bridges of this capability encapsulate customer frames using
provider provisioned backbone MAC header. This is similar concept as
edge router encapsulating IP packet in GMPLS prefixed frame,
explained in section 4.1, except that the payload is now customer MAC
frame. Once a customer MAC frame is encapsulated by provider MAC
frame, the frame is forwarded using the provider MAC header while
progressing in the core network. The provider MAC header is stripped
off at egress edge bridge of the MAC-in-MAC tunnel.
Currently this concept of MAC-in-MAC tunnel service is being defined
in IEEE 802.1ah (Provider Backbone Bridge), although the document
doesn't specifically refer use of multicast address for backbone MAC
header. The MAC-in-MAC tunnel can be controlled by GMPLS when GMPLS
J.Cho, et.al. Expires - July 2006 [Page 9]
Label Switched Ethernet Architecture July 2006
is used for delivering edge information between 802.1ah bridges, such
as B-MAC information.
The proposed MAC-in-MAC tunnel shows some appropriate characteristics
in servicing Ethernet user. For example, compared to the scale
limitation of VLAN, this approach allows up to 16 million MAC-in-MAC
tunnels being established in an administrative domain, when a block
of 24bit multicast addresses is reserved for the tunnel address. In
fact, there is no limitation of the number of tunnels when any
private MAC address is allowed for the tunnel address.
The termination point of MAC-in-MAC tunnel service can be an internal
port of edge bridge, an external port, or even an abstract port. When
an external port servicing an Ethernet customer is the demarcation
point of MAC-in-MAC service, the customer is free to define their own
VLANs up to the limit of VLAN scale. Multiple MAC-in-MAC tunnels may
also be provided for each VLANs at a port.
5.4 Interoperation with GMPLS unaware bridges
While the IP service model presented in section 4.1 assumes
homogeneous deployment of GMPLS for convenience of description, this
proposal does not mandate GMPLS being deployed in all core nodes to
initiate operation. GMPLS unaware bridges may coexist in the network
and participate in delivering GMPLS frames. In this case, a VLAN for
GMPLS must be configured in both GMPLS implemented bridges and
unaware bridges.
Since GMPLS implemented bridges have ability to control multicast
frames and avoid looping, the GMPLS bridges set forwarding state of
the VLAN in all ports and take all ports in consideration of shortest
path computation. However the GMPLS unaware bridges may not have such
ability, hence, filtering state of the VLAN must be configured
carefully in those bridges that unexpected looping of multicast
frames is prevented.
There can be several methods to prevent looping of multicast frames
in legacy bridges. Figure 4 below shows an example of VLAN
configuration where GMPLS implemented bridges, G1 and G2, share
common LAN segment with GMPLS unaware bridges, B1 and B2. R1 and R2
describe edge routers supporting GMPLS implementation. The GMPLS
implemented bridges configured the VLAN in all ports and use all
ports for forwarding multicast frames.
When one of the GMPLS unaware bridges configured forwarding state of
the VLAN, other bridge that sharing the common LAN segment must
filter the VLAN in order to prevent looping between the bridges.
J.Cho, et.al. Expires - July 2006 [Page 10]
Label Switched Ethernet Architecture July 2006
Figure 4 illustrates that B2 set filtering state of the VLAN in one
of the ports, as a result, GMPLS frames pass only through B1.
|
+-+-+
| R1|
+-+-+
|
=========================
| |
+-+-+ +-+-+
| G1| | G2|
+-+-+ +-+-+
| |
=========================
| |
+-+-+ +-+-+
| B1| | B2|
+-+-+ +-+-+
| : VLAN
| x Filtered
| :
=========================
|
+-+-+
| R2| | VLAN Configured
+-+-+ : VLAN Filtered
|
Figure 4. VLAN Configuration in GMPLS Unaware Bridges
When B1 and B2 are capable of supporting GMRP (GARP Multicast Routing
Protocol) or IGMP (Internet Group Management Protocol), GMPLS
implemented bridges may interact with the GMPLS unaware bridges using
the protocols and precisely control LSP path in those bridges. Detail
of the interoperation with GMPLS unaware bridges is out of the scope
in this document.
J.Cho, et.al. Expires - July 2006 [Page 11]
Label Switching Ethernet Architecture July 2006
6. Inter-domain Extension and Future Work
In this version of document, the proposed LSE method only applies to
intra-domain case where allocation of multicast address is
administered by single organization. This allows up to 16 million
LSPs being established in a bridged core network which is enough in
most scale of single administrative domain.
When two bridged network of different administrative domains need to
be interconnected, this document recommends using upper layer
protocol relay, such as MPLS LSR or IP router. Layer-2 connectivity
of LSP is terminated at the border of domain.
Currently, work is in progress in IEEE 802.1ah to provide layer-2
connectivity in inter-domain scale. A solution being considered is
extension of MAC-in-MAC tunnel across multiple inter-domain networks.
Since LSE also supports MAC-in-MAC tunnel, it is expected that any
inter-domain solution devised in 802.1ah may equally be applied to
this proposal.
J.Cho, et.al. Expires - July 2006 [Page 12]
Label Switching Ethernet Architecture July 2006
Security Considerations
Some security issue has been discussed in section 3 and 4.2
References
[IEEE802] IEEE Computer Society, "IEEE Standard for Local and
Metropolitan Area Networks:Overview and Architecture", IEEE Std
802-2001, IEEE Standard Document, 8 March 2002
[IEEE8021D] IEEE Computer Society, "Media Access Control (MAC)
Bridges", IEEE Std 802.1D-2004, IEEE Standard Document, 9 June
2004
[IEEE8021Q] IEEE Computer Society, "Virtual Bridged Local Area
Network", IEEE Std 802.1Q 2003 Edition, IEEE Standard Document, 7
May 2003
[IEEE8021AD] IEEE Computer Society, "Virtual Bridged Local Area
Networks - Amendment 4 : Provider Bridges", P802.1ad/D6.0, Draft,
Work in Progress
[IEEE8021AG] IEEE Computer Society, "Virtual Bridged Local Area
Networks - Amendment 5 : Connectivity Fault Management",
P802.1ag/D5.2, Draft, Work in Progress
[IEEE8021AG] IEEE Computer Society, "Virtual Bridged Local Area
Networks - Amendment 6 : Provider Backbone Bridges",
P802.1ah/D1.52, Draft, Work in Progress
[RFC3945] E. Mannie, "Generalized Multi-Protocol Label Switching
(GMPLS) Architecture", RFC3945, Oct 2004
J.Cho, et.al. Expires - July 2006 [Page 13]
Label Switching Ethernet Architecture July 2006
Author's Addresses
Jaihyung Cho (ETRI)
161 Gajung Dong,
Yuseong Gu, Daejeon, Korea
Phone: +82 42 860 5514
Email: jaihyung@chol.com
Dae Young Kim (Chung Nam National University)
Email: dykim@cnu.ac.kr
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
J.Cho, et.al. Expires - July 2006 [Page 14]
Label Switching Ethernet Architecture July 2006
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.
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 - July 2006 [Page 15]
