PPVPN Working Group K. Kompella (Juniper)
Internet Draft J. Achirica (Telefonica)
Expiration Date: April 2002 L. Andersson (Utfors)
M. Lasserre (Riverstone)
P. Lin (Yipes)
P. Menezes (Terabeam)
A. Moranganti (Appian)
H. Ould-Brahim (Nortel)
S. Yeong-il (Korea Tel)
Decoupled Transparent LAN Services
draft-kompella-ppvpn-dtls-00.txt
1. Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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.
K. Kompella (editor) Expires April 2002 [Page 1]
Internet Draft draft-kompella-ppvpn-dtls-00.txt October 2001
2. Abstract
Transparent LAN Service (TLS) is a useful Service Provider offering.
A common scenario where this offering is made is in the metro area,
where several Multi-Tenant buildings are connected to an Office, and
several Offices are connected by a metro area network. The Service
Provider places a simple, low-cost box (MTU) in each building; these
MTUs have uplinks to some box (PE) in one or more Offices. In such a
scenario, it is useful to decouple the functions needed to offer TLS
across the MTU and PE; this document proposes one way of
accomplishing that.
3. Introduction
Transparent LAN Service (TLS) is a useful Service Provider offering.
A Transparent LAN appears in (almost) all respects as a LAN to the
Service Provider customer; "transparent" is used in the sense of
"transparent" bridging. However, in a TLS, the customers are not all
connected to a single LAN; the customers may be spread across a metro
or wide area. In essence, a TLS glues several individual LANs across
a metro area to appear and function as a single LAN.
A common scenario where TLS is offered is in the metro area, where
several Multi-Tenant buildings are connected to an Office, and
several Offices are connected by a metro area network, for example, a
SONET ring. The Service Provider places a simple, low-cost box (MTU)
in each building. A typical MTU has 10-100 Ethernet ports that
connect to customers (we call these the "customer-facing ports"), and
one or more uplinks to a Service Provider aggregation box (PE) (we
call these the "WAN" links, although they may either metro area or
wide area links). The customer hand-off is thus an Ethernet; the MTU
acts as a metro/wide area bridge connecting the LAN at a customer
site to other MTUs that are connected to other LANs belonging to the
same customer.
In such a scenario, it is useful to decouple the functions needed to
offer TLS across the MTU and PE. These functions comprise learning
MAC addresses, including learning across the metro area from other
MTUs; building a spanning tree, both on the LAN side and on the metro
side; and discovering other MTUs connected to a given customer. This
document suggests that the former two functions (layer 2 functions)
be run on the MTU, and that the last function (layer 3) be run on the
PE. In addition, there needs to be some information exchange between
the PE and its MTUs. This document does not suggest that decoupling
is appropriate for all scenarios.
The spanning tree algorithm is useful in the case that an MTU is
K. Kompella (editor) Expires April 2002 [Page 2]
Internet Draft draft-kompella-ppvpn-dtls-00.txt October 2001
connected to more than one PE which can reach a destination MTU.
This gives the MTU a means to choosing one of the PEs as the primary
means of reaching the destination MTU, while preserving the others as
backup paths. Alternative means of accomplishing this objective may
be possible, and indeed, preferable, and are not ruled out by this
document.
3.1. Motivation for Decoupling
We consider three ways of splitting the TLS functions across the MTU
and PE: run all TLS functions on the MTU; run all TLS functions on
the PE; or run learning and spanning tree on the MTU, and discovery
on the PE, and some information exchange between them. In this
subsection, we examine the repercussions of each.
3.1.1. Function Compatibility
In this document, we assume that an MTU is a simple, low-cost layer 2
device, usually based on a bridge. That implies that an MTU is
designed to learn MAC addresses, and to run a spanning tree
algorithm. An MTU does not usually run complex layer 3 protocols, in
particular, BGP, which is the de facto VPN discovery protocol.
On the other hand, a PE device is a more complex layer 3 device.
Besides being connected to MTUs and offering TLS, a PE may offer
several other services. For example, a PE may be directly connected
to customers through WAN circuits to offer various VPN services,
and/or public Internet access; and a PE may take part in peering
sessions. This requires the PE to be capable of VPN discovery, and
to run BGP, so it is natural for a PE to do TLS discovery.
3.1.2. Scalability
Let's posit the following hypothetical numbers to get a feel for the
scaling requirements. The numbers are just orders of magnitude;
there is no claim that these are realistic, or supported by market
data.
# of end hosts per TLS 100-1000
# of TLS's per MTU 10-100
# of MTUs per PE 10-100
# of PEs in a metro area 10-100
Armed with these, let's examine the effect of running each of the TLS
functions at an MTU vs. at the PE.
K. Kompella (editor) Expires April 2002 [Page 3]
Internet Draft draft-kompella-ppvpn-dtls-00.txt October 2001
The number of MAC addresses that would need to be learned by an MTU
ranges from 1000 to 100,000. The number that would need to be
learned by a PE ranges from 10,000 to 10,000,000.
A spanning tree may need to be built for each TLS. If so, the number
of spanning trees that would need to be built by an MTU ranges from
10 to a 100. The number of spanning trees that would need to be
built by a PE ranges from 100 to 10,000.
The number of "discovery peers" (i.e., BGP peers if BGP is the
discovery protocol) for an MTU doing discovery ranges from 100 to
10,000. The number of peers for a PE doing discovery ranges from 10
to 100. (Note that the number of peers can be mitigated using
techniques similar to those recommended for RFC 2547-style VPNs
[IPVPN, IPVPNbis], e.g., partitioned route-reflector topologies.)
3.1.3. Configuration
Both the fact that the MTU is a simple, low-cost box, and that there
are one to two orders of magnitude more MTUs than PEs suggest that
the PE is more suitable as the place where TLS should be configured.
If all TLS functions are run on the PE, this is automatically
satisfied. If all TLS functions are run on the MTU, this is
difficult to achieve. This document shows how this can be achieved
in the case that the TLS functions are distributed across the MTU and
PE.
4. Functional Requirements
This section presents the functional requirements of MTUs and PEs in
order to participate in a decoupled TLS.
4.1. Requirements on the MTU
An MTU must be able to function as a transparent learning bridge, as
it might well be connected to traditional bridges on customer-facing
ports. Thus, it must be able to learn MAC addresses and run the
spanning tree algorithm and flood packets when necessary. An MTU
must also be able to run the modified learning and spanning tree
algorithms described below, as well as the modified flooding.
In addition, an MTU must be able to send and receive labeled packets.
This labeling could either be MPLS labels, or VLAN tagging. In the
latter case, the VLAN tag could either be the first tag, or a stacked
tag; unfortunately, there is no standard yet for VLAN stacking. It
K. Kompella (editor) Expires April 2002 [Page 4]
Internet Draft draft-kompella-ppvpn-dtls-00.txt October 2001
is absolutely necessary that the VLAN tag that is added is assigned
by the Service Provider, and is independent of customer tags. More
details on the use of VLAN tags between an MTU and a PE will be
forthcoming in a future version of this document.
For MPLS labeling, an MTU must be able to take an Ethernet frame from
a customer-facing port, verify the CRC, strip the Ethernet preamble
and CRC, and encapsulate the remaining Layer 2 frame as an MPLS
packet with the appropriate label stack and send it to a PE. On the
receiving side, the MTU must be able to receive a labeled packet from
a PE, and based on the label decide which TLS the enclosed Ethernet
frame belongs to; if necessary, learn the origin of the source MAC
address (as described in the section on modified learning); remove
the MPLS encapsulation and label; and generate a CRC and send the
packet on the appropriate customer-facing port. Furthermore, the MTU
must be able to distinguish from which PE it received the labeled
packet, i.e., it must support per-interface labels, for reasons
described below.
Also, an MTU should have some means to be provisioned and to monitor
its operation. This requires some form of access to the MTU; for
example, if the provisioning and monitoring is to be done via SNMP,
the MTU would have to be IP-addressable, and to support SNMP
functions.
Finally, an MTU must run the MTU-PE protocol described below, and to
carry out the actions required by the protocol.
In order to accomplish the above, the MTU may maintain in some form a
mapping from (learned) MAC addresses to customer ports (for
traditional learning), and a mapping from MAC addresses to received
labels (for the modified learning); these mappings constitute the
MTU's MAC address cache. Ideally, the MTU should maintain a separate
MAC address cache for each TLS it is part of, although in principle
MAC addresses being globally unique, this should not be necessary.
Also, the MTU must have a (configured) mapping from a customer port
to a TLS, and for convenience, a mapping from a TLS to a list of
customer ports.
4.2. Requirements on the PE
A PE must have the Layer 2 VPN functionality described in [L2VPN],
with the modifications described below. This requires that a PE be
able to run BGP; MPLS: i.e., send and receive labeled packets, and
swap, push and pop labels; and that a PE have some form of tunnels to
every other PE taking part in any TLS in which this PE is
participating.
K. Kompella (editor) Expires April 2002 [Page 5]
Internet Draft draft-kompella-ppvpn-dtls-00.txt October 2001
A PE must also support the configuration of TLSs, and be able to run
the MTU-PE protocol described below.
5. PE Operation
This section describes how a PE running a decoupled TLS operates,
that is, how the TLS is configured, how members are discovered, how
the PE forwards packets in a TLS.
The discovery mechanism used here is a variant of the Layer 2 VPN
discovery [L2VPN]. Familiarity with that document is a prerequisite
to understanding the operation of decoupled TLSs as described here.
5.1. Configuration
We first list the configuration information that MTUs and PEs need,
then we suggest a means of configuring this information.
As we said earlier, an MTU has several Ethernet ports that connect to
customers, and some uplinks to PEs. The MTU needs to be told which
of its customer-facing ports belong in which TLS. More precisely,
the MTU needs to be told which TLSs it is a member of, and which PEs
it is connected to. For each <PE, TLS> pair, the MTU must be told
what its "site ID" is for that <PE, TLS>. Finally, for each TLS, the
MTU must be given the list of its <physical port, VLAN>s that belong
to the TLS.
A PE needs to be told which MTUs it is connected to (and over which
link), and which TLSs each such MTU participates in.
The minimum information that a PE must be configured with is the
following:
<<MTU ID (router ID)>
<connecting interface>
<<TLS ID> <MTU site ID>
<<TLS ID> <MTU site ID>
...
>
That is, the PE is given the MTU ID (as an IP address), the interface
over which it is connected to the MTU, and a list of TLSs that that
MTU participates in. For each TLS in this list, the PE is given the
TLS ID, the MTU's site ID in this TLS. A TLS ID is an 8 octet Route
Distinguisher; a site ID is a two octet integer (see [L2VPN] for
details).
K. Kompella (editor) Expires April 2002 [Page 6]
Internet Draft draft-kompella-ppvpn-dtls-00.txt October 2001
If it is desired that all TLS configuration be done at the PE, here
is how this can be accomplished. The PE is configured with the
following information for each MTU to which it is connected:
<<MTU ID (router ID)>
<connecting interface>
<<TLS ID> <MTU site ID>
<<MTU port ID, VLAN tag> <MTU port ID, VLAN tag> ...>>
<<TLS ID> <MTU site ID>
<<MTU port ID, VLAN tag> <MTU port ID, VLAN tag> ...>>
...
>
That is, in addition to the above, the PE is given, for each MTU and
each TLS that the MTU participates in, a list of customer facing port
IDs and corresponding VLAN tags that belong to that TLS. An MTU port
ID is a two octet integer; a VLAN tag is a two octet (12 bit) 802.1q
tag.
The PE then transfers all information relevant to an MTU to that MTU
using the MTU-PE protocol described later. The PE transfers all
information relevant to other PEs running TLS to them using a
mechanism similar to [L2VPN], described below.
5.2. Generated Information
A PE given the above configuration generates label ranges as in
[L2VPN] consisting of a label base, an offset and a size. It is
expected that for a TLS, a single, contiguous label range with offset
0 would suffice; if not, a number of non-overlapping label ranges can
be used, as described in [L2VPN]. Call these label ranges the WAN
label ranges for the <MTU, TLS> pair.
For the same <MTU, TLS> pair, the PE must generate a second set of
label ranges called the MTU label ranges. Each MTU label range for
an <MTU, TLS> pair corresponds exactly to one of the WAN label ranges
for the <MTU, TLS>; in fact, the only difference is the label base.
All WAN label ranges generated by a given PE must be non-overlapping;
similarly, all MTU label ranges generated by a given PE must be non-
overlapping. It is possible that some WAN label range and some MTU
label range overlap; this depends on factors outside the scope of
this document (such as whether per-interface or per-box labels are
being used). An implementation may of course choose to ensure that
PE WAN labels and MTU labels are always non-overlapping.
K. Kompella (editor) Expires April 2002 [Page 7]
Internet Draft draft-kompella-ppvpn-dtls-00.txt October 2001
5.2.1. Multipoint Uplinks
If the PE-MTU link is a multipoint link (such as Ethernet), and there
are multiple PEs on this link, there is the possibility that the MTU
label ranges from the PEs overlap. In this case, some mechanism is
needed to resolve the overlap.
One solution is that PEs that are connected to MTUs over a multipoint
link multicast their messages to the MTUs, say to the ALL-ROUTERS
multicast address. If PE y hears that PE x is using a certain label
range, it remembers that, and ensures that future label ranges that
it sends to an MTU don't overlap. If two PEs send overlapping label
ranges simultaneously, the PE with the lower router ID wins the
contention, and the other PE withdraws its label range and issues a
non-overlapping range. Details will be forthcoming.
Other solutions may also be possible.
5.3. TLS Discovery
The mechanism used for TLS member discovery is that in [L2VPN], with
the following changes: there is a new code-point for encapsulations
for Decoupled TLS; and the "routes" that are installed are different
(described next). Furthermore, it is anticipated that there is no
need for topology information, as TLSs are fully meshed. For
simplicity, it is assumed that a single label range with offset 0 is
used for both WAN and MTU label ranges for a given <MTU, TLS> pair.
Say MTU U is attached to PE X, and that MTU U participates in TLS T.
Suppose MTU U' attached to PE X' also participates in TLS T. Suppose
further that the site ID for MTU U in TLS T is p, and the site ID for
MTU U' is p'. Suppose finally that there is a tunnel W from PE X to
PE X' and a reverse tunnel W' from PE X' to PE X.
PE X announces a WAN label range to all other PEs with label base K,
offset 0, and length k (k >= p, p') for <MTU U, TLS T>. According to
[L2VPN], this tells PE X' to use label (K+p') to send packets from
MTU U' to MTU U. PE X' announces a WAN label range to all other PEs
with label base K', offset 0, and length k' (k' >= p, p') for <MTU
U', TLS T>. This tells PE X to use label (K'+p) to send packets from
MTU U to MTU U'.
PE X also sends an MTU label range to MTU U with label base A, offset
0, and length k for TLS T. This tells MTU U to use label (A+p') to
send to the MTU with site ID p' (i.e., MTU U'); and also that packets
received with label (A+p') belong to TLS T, and were originated at
the MTU with site ID p'. Similarly, PE X' sends an MTU label range
K. Kompella (editor) Expires April 2002 [Page 8]
Internet Draft draft-kompella-ppvpn-dtls-00.txt October 2001
to MTU U' with label base A', offset 0, and length k' for TLS T.
PE X installs "MTU routes" and "WAN routes". We describe the MTU
route for packets from MTU U to MTU U': for labeled packets arriving
from MTU U, swap incoming label (A+p') with (K'+p), then put the
packet in tunnel W to PE X'. The WAN route is for packets from MTU
U' to MTU U, and is as follows: for packets arriving on tunnel W'
from PE X', remove the packets from the tunnel (if needed), then swap
incoming label (K+p') with label (A+p').
To complete the path from MTU U to MTU U', the WAN route installed by
PE X' is described. For packets arriving on tunnel W from PE X,
remove the packets from the tunnel (if needed), then swap incoming
label (K'+p) with (A'+p).
Figure 1 below depicts this scenario: MTU U connected to PE X and MTU
U' connected to PE X'. It further depicts MTU U dual homed to PE Z,
and another MTU V dual homed to the same PE, PE Y. For each PE, it
shows the WAN label range announced to other PEs, as well as the MTU
label range sent to its MTU. Note that a dual homed MTU MUST be
given distinct site IDs for each uplink, whether to the same PE or
different PEs; and that a PE must allocate and announce WAN and MTU
label ranges for each MTU that it is connected, even if it is the
same MTU over different links (such as PE Y and MTU V).
Figure 1
{A,0,k} <- +-------+ W -> +-------+ -> {A',0,k'}
============| PE X |<****************>| PE X' |=======[MTU U']
| +-------+ W' <- +-------+
| announces {K,0,k} \ / announces {K',0,k'}
| for MTU U, site ID p\ / for MTU U', site ID p'
| ..............
[MTU U] . core .
| .............. announces {L,0,l} for
| announces {M,0,m} / \ MTU V, site ID q
| MTU U, site ID r / announces \ -> {B,0,l}
| +-------+ {L',0,l'} +-------+=======[ ]
============| PE Z | for MTU V, | PE Y | [MTU V]
{C,0,m} <- +-------+ site ID q' +-------+=======[ ]
-> {B',0,l'}
K. Kompella (editor) Expires April 2002 [Page 9]
Internet Draft draft-kompella-ppvpn-dtls-00.txt October 2001
5.4. Packet Forwarding
All TLS packets from/to the MTU to/from its PE are sent as labeled
packets: the entire Ethernet frame (minus preamble and checksum) is
encapsulated in an MPLS frame with a single label. This label
encodes both the TLS to which the packet belongs, as well as the
source (for packets received) or destination (for packets sent).
TLS packets from PE to PE are sent as a single label MPLS packet in a
PE-PE tunnel. Thus, the packet may be an MPLS packet with a two or
more label stack; or it may be MPLS in a GRE or IPSec tunnel, etc.
Say an endpoint "behind" MTU U decides to send a TLS T packet to some
endpoint "behind" MTU U'. All MTU U knows about MTU U' is that its
site ID is p', i.e., to send packets to MTU U', MTU U must use label
(A+p') (how it arrives at this is described in the section on
learning). The MTU route at PE X states that the label (A+p') is
swapped with (K'+p), and the packet is put in tunnel W to PE X'.
When PE X' gets the packet, it removes the packet from the tunnel,
and sees label (K'+p). PE X' swaps the label with (A'+p) per its MTU
route, and sends this packet to MTU U'. Seeing label (A'+p), MTU U'
knows that the packet is a TLS T packet which originated at MTU U
(i.e., the MTU with site ID p).
6. MTU Operation
This section describes the information that an MTU gets from its PE,
and how learning and spanning tree computations are done in a TLS.
Modified flooding and learning in the case that the MTU-PE labeling
is done using VLANs is entirely analogous, and will be detailed in a
future version of this document.
6.1. MTU-PE Information Exchange
The PE sends the following information to attached MTUs:
<<PE ID (router ID)> <MTU ID (router ID)>
<<TLS ID> <MTU site ID>
<<MTU label range> <MTU label range> ...>
<<MTU port ID, VLAN tag> <MTU port ID, VLAN tag> ...>>
<<TLS ID> <MTU site ID>
<<MTU label range> <MTU label range> ...>
<<MTU port ID, VLAN tag> <MTU port ID, VLAN tag> ...>>
...
>
K. Kompella (editor) Expires April 2002 [Page 10]
Internet Draft draft-kompella-ppvpn-dtls-00.txt October 2001
That is, the PE sends its own ID, the MTU's ID (for sanity checking),
and a list of TLS IDs. For each TLS, the PE tells the MTU its site
ID in the TLS, a list of MTU label ranges, and a list of customer
ports in the TLS. (The last list is for the MTU's private
consumption, and is optional.) An MTU label range consists of a
label base, a site ID offset, the number of sites in the range, and a
bit vector of currently active sites. The length of the bit vector
in octets is (number of sites in the range)/8.
The exact format of this information, and the protocol that is used
to transfer this information, as well as a list of status codes sent
by the MTU in response will be specified in greater detail in a later
version.
6.2. Modified Flooding
Flooding is used for example when an MTU wants to send a packet, but
doesn't have the packet destination MAC address in its MAC address
cache; or when the destination MAC address is a broadcast or
multicast address. Such a packet may be received either from a
customer port, or from a PE. The MTU must first identify to which
TLS the packet belongs. It must then flood this packet, i.e., send a
copy of the packet out on multiple ports. If the packet is received
on a customer port, the MTU must send a copy out on every other
customer port in the TLS, as well as to every other MTU participating
in the TLS. If the packet is received from a PE, then the packet
must be sent on every customer port; if the TLS is a full mesh, the
packet need not be sent to any other PE/MTU. If the TLS is not a
full mesh, the MTU must be told to which other PE/MTUs it needs to
flood the packet.
If an MTU wants to flood a TLS packet to all other MTUs in the TLS,
the MTU sends a copy of the packet with each label in the MTU label
ranges for that TLS (except of course the label corresponding to the
MTU itself) and sends it to the PE. If an MTU has multiple
connections to PEs (the same or different), it MUST flood to each PE
over each available connection.
6.3. Modified Learning
When MTU x receives a packet from one of its PEs, it matches the
incoming label with all the MTU label ranges received from the
sending PE. (Note: MTU label ranges sent by a PE to an MTU MUST be
non-overlapping. However, an MTU label range sent by one PE MAY
overlap with an MTU label range sent by another PE. An MTU MUST be
able to identify the interface over which a packet arrived, and use
K. Kompella (editor) Expires April 2002 [Page 11]
Internet Draft draft-kompella-ppvpn-dtls-00.txt October 2001
that information to disambiguate incoming labels.)
The incoming label tells MTU x which TLS this packet belongs to, and
which MTU it originated at (say x'). If the source MAC address S of
the packet is not in the MAC address cache of MTU x, MTU x "learns" S
by remembering the site ID of MTU x' (or more simply, by associating
S with the incoming label L). If at some future point, MTU x wants
to send a packet to destination MAC address S, it looks up its cache,
sees that S maps to label L, pushes label L and sends it to its PE.
6.4. Modified Spanning Tree
An MTU x will receive multiple copies of a flooded packet with a
given source MAC address S from MTU y if either MTU x or MTU y (or
both) is multiply connected to PEs; each copy of the packet will be
received with a distinct <incoming interface, MTU label> pair. In
that case, MTU x must choose which <outgoing interface, MTU label>
pair it will use to get to MAC address S. This situation corresponds
exactly to there being multiple ports connecting two bridges. If the
TLS is fully meshed, MTU x can choose on its own which <interface,
label> to use to send packets to MAC address S; i.e., MTUs need not
run a spanning tree algorithm across the metro or wide area which may
be a distinct benefit.
If a TLS is not fully meshed, each MTU in the TLS may treat multiple
incoming MTU labels for a given MAC address as multiple parallel
ports to the same "bridge" (i.e., remote MTU) and use the spanning
tree algorithm to pick the active port (i.e., label) to use to reach
the MAC address.
Finally, MTU may use an IGP (or configuration) to decide which of the
multiple incoming MTU labels to use to map a given source MAC
address.
6.5. Load Balancing
If an MTU is multi-homed (i.e., it has multiple uplinks to one or
more PEs), it may decide to load balance across those links. This
decision can be made locally by the MTU. The main consideration is
to make sure that packets to the same destination use the same path
to avoid packet re-ordering. This can be tricky, as broadcast or
multicast packets may go to the same destination. A reasonable
approach is to use the same uplink for all packets in a given TLS,
but to use different uplinks for different TLSs, thus achieving some
degree of load balancing.
K. Kompella (editor) Expires April 2002 [Page 12]
Internet Draft draft-kompella-ppvpn-dtls-00.txt October 2001
7. Security Considerations
The security aspects of this solution will be discussed at a later
time.
8. IANA Considerations
(To be filled in in a later revision.)
9. Acknowledgments
Many thanks to Brian Brown, Ian Hood, Vasile Radaoca and the Juniper
"ethernet geeks", from whose stimulating discussions this idea was
born; and to Yakov Rekhter whose probing questions helped clarify and
refine the details.
10. References
[IPVPN] Rosen, E., and Rekhter, Y., "BGP/MPLS VPNs", RFC 2547, March
1999.
[IPVPNbis] Rosen, E., et al, "BGP/MPLS VPNs", work in progress.
[L2VPN] Kompella, K., et al, "MPLS-based Layer 2 VPNs", work in
progress.
11. Intellectual Property Considerations
Juniper Networks may seek patent or other intellectual property
protection for some of all of the technologies disclosed in this
document. If any standards arising from this document are or become
protected by one or more patents assigned to Juniper Networks,
Juniper intends to disclose those patents and license them on
reasonable and non-discriminatory terms.
K. Kompella (editor) Expires April 2002 [Page 13]
Internet Draft draft-kompella-ppvpn-dtls-00.txt October 2001
12. Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
13. Author Information
Yeong-il,Seo
Korea Telecom
Telecommunication Network Laboratory
Member of Technical Staff
463-1 Junmin-dong, Yusung-gu, Taejeon, Korea
Tel : +82-42-870-8333 / FAX : +82-42-870-8339
Mobile : 016-235-0135 / E-mail : syi@hana.ne.kr
Hamid Ould-Brahim
Nortel Networks
P O Box 3511 Station C
Ottawa ON K1Y 4H7 Canada
Phone: +1 (613) 765 3418
Email: hbrahim@nortelnetworks.com
Ashwin Moranganti
Appian Communications
K. Kompella (editor) Expires April 2002 [Page 14]
Internet Draft draft-kompella-ppvpn-dtls-00.txt October 2001
email: amoranganti@appiancom.com
phone: 978 206-7248
Pascal Menezes
Terabeam Networks, Inc.
14833 NE 87th St.
Redmond, WA, USA
phone: (206) 686-2001
email: Pascal.Menezes@Terabeam.com
Pierre Lin
Yipes Communications, Inc.
114 Sansome St.
San Francisco CA 94104
email: pierre.lin@yipes.com
Marc Lasserre
Riverstone Networks
5200 Great America Parkway
Santa Clara CA 95054
marc@riverstonenet.com
Loa Andersson
Utfors AB
Box 525, 169 29 Solna
Sweden
phone: +46 8 5270 5038
email: loa.andersson@utfors.se
Javier Achirica
Telefonica Data
javier.achirica@telefonica-data.com
Kireeti Kompella
Juniper Networks
1194 N. Mathilda Ave
Sunnyvale, CA 94089
kireeti@juniper.net
K. Kompella (editor) Expires April 2002 [Page 15]