Internet-Draft Generalized Ethernet Pseudowire July 2008
Internet Draft Document Vach Kompella
Category: Standards Track Florin Balus
Expires: January 2009 Alcatel-Lucent
Andrew Malis
Verizon
Shane Amante
Level 3
Giles Heron
British Telecom
July 2008
Generic Ethernet Pseudowire
draft-vkompella-pwe3-ethernet-pw-bis-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 in January 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
V. Kompella Expires January 2009 [Page 1]
Internet-Draft Generalized Ethernet Pseudowire July 2008
Abstract
This draft proposes a simpler approach to handling various
encapsulations of Ethernet packets over a pseudowire, over the
existing Ethernet Pseudowire definition in [RFC4448].
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 [RFC2119].
1. Introduction
In this draft, we describe a methodology for encapsulating Ethernet
packets in pseudowires that eliminates the need for multiple
encapsulation formats and pseudowire code-points when Ethernet
formats change. This draft extends the concepts already published
in [RFC4448].
[RFC4448] defines two different pseudowire types for Ethernet
packets, one where the packet transported over the pseudowire must
have a service delimiting VLAN tag (Ethernet tagged type), and the
other where it does not need to have one (Ethernet type) as per
[IANA PWE3]. The original justification for the tagged PW type came
from the need to accommodate routers that could not handle standard
Ethernet functions like imposing, stripping or rewriting VLAN tags.
This draft has been written in response to the following statements
from [RFC4448] and consequent concerns that as new Ethernet formats
(such as Provider Backbone Bridging, PBB I-tag [802.1ah]) are
defined, corresponding pseudowires have to be defined:
- For an Ethernet VLAN PW, VLAN tag rewrite can be achieved by
NSP at the egress PE, which is outside the scope of this
document ([RFC4448], Section 3).
- The Ethernet or Ethernet VLAN PW only supports homogeneous
Ethernet frame type across the PW; both ends of the PW must be
either tagged or untagged. Heterogeneous frame type support
achieved with NSP functionality is outside the scope of this
document ([RFC4448], Section 3).
This document proposes a Generic Ethernet PW (GE-PW) that extends
the definition of Ethernet PWs and their usage in the existing
L2VPNs (VPWS, VPLS) and simplifies the development of future
solutions that require transport of Ethernet frames over a
pseudowire.
V. Kompella Expires January 2009 [Page 2]
Internet-Draft Generalized Ethernet Pseudowire July 2008
2. The Generalized Ethernet Pseudowire
To define the Generalized Ethernet Pseudowire (GE-PW) we need to
describe the following functions:
- the packets eligible to be placed in a GE-PW
- the processing functions outside the scope of the GE-PW
- the processing functions within the scope of the GE-PW
2.1. Eligible Packets in the GE-PW
Any ethernet packet defined by the IEEE is an eligible packet for
the GE-PW, regardless of the type of tags it contains - e.g. IEEE
802.1Q, 802.1ad, 802.1ah tags. The Ethernet header is defined with a
set of well defined code points that can be used by the NSP to
identify the type of tag and the following header fields and to
process the frame accordingly.
A new Interface Parameter sub-TLV is defined to describe the
capabilities of the NSP function to adapt different ethernet
encapsulations as packets arrive from the pseudowire and are
delivered to the attachment circuit. Section 4 describes the
applicability and the format for the new sub-TLV.
2.2. Processing outside the scope of the GE-PW
When an ethernet packet is received on an attachment circuit (AC),
it may be processed before being passed to the PW termination
function. This processing is done by the NSP function which has the
responsibility of removing service delimiting encapsulations on the
packet, and identifying the PW that the packet is bound for.
When a packet arrives on a PW, the PW service label is used to
identify the particular service instance and subsequently the NSP
function that is applied to the ethernet packet at the egress PE.
The NSP function puts on the appropriate ethernet encapsulation
before passing the packet on to the attachment circuit(s) associated
with the NSP.
The processing of the Ethernet frames at the ingress and egress NSPs
are outside the scope of the GE-PW.
2.3. Processing within the scope of the GE-PW
A packet passed to the PW termination function by the ingress NSP at
the ingress PE is encapsulated with the appropriate PW label and is
passed to the PSN function for encapsulation and transport to the
V. Kompella Expires January 2009 [Page 3]
Internet-Draft Generalized Ethernet Pseudowire July 2008
egress PE. A packet arriving on a pseudowire egress has its PW label
popped, and the resulting packet is passed to the appropriate NSP
instance.
3. Detailed processing steps
There are four main processing points in using a pseudowire: the
ingress NSP function, the ingress PW termination function, the
egress PW termination function, and the egress NSP function.
Although just the PW termination functions are relevant for GE-PW,
this section discusses how the GE-PW can be used with different
types of existing NSPs to emulate existing and future services.
In order to more clearly illustrate how a GE-PW may be used to
provide pseudowire services, we introduce the following terms.
These terms are to be used as a guideline to understanding the
behavior of a GE-PW, and in no way define an implementation:
- In-NSP(packet, options): the ingress NSP function, includes the
ingress attachment circuit (AC) function
- In-PW(packet, options): the ingress PW termination function
- Out-PW(packet, options): the egress PW termination function
- Out-NSP(packet, options): the egress NSP function, includes the
egress AC function
In addition, we define the pseudowire context (PWC) as the construct
which has, at ingress, the following information:
- the incoming encapsulation of the packet
- the In-NSP function to be applied on the packet
- the In-PW termination function to be applied
- the ingress PSN encapsulation information to be applied
and at egress:
- the Out-PW termination function to be applied
- the Out-NSP function to be applied on the packet
- the outgoing encapsulation of the packet on the attachment
circuit
Using the above functions, we will define actions at the various
stages of the packet through the network that affect its behavior.
In particular, we will show the capabilities in describing the two
existing Ethernet pseudowires, and introduction of a number of
standard VLL service types that are enabled as a consequence of
implementing the GE-PW methods.
V. Kompella Expires January 2009 [Page 4]
Internet-Draft Generalized Ethernet Pseudowire July 2008
As the packet arrives from the customer, at the In-NSP function, the
NSP may remove the FCS and any extraneous packet header information
that is locally significant [RFC4448]. The optional method described
in [RFC4720] can be used to achieve payload integrity transparency.
In particular, the function of the In-NSP is to render the packet
ready for consumption by the remote Out-NSP function. In other
words, the In-NSP must replace, remove or impose VLAN tags, PBB I-
tag or any required Ethernet headers so that the packet is
recognizable by the egress NSP. It performs also functions specific
to the type of native service that is rendered at the ingress PE,
for example MAC switching, MAC learning, packet replication for
VPLS. Finally, the In-NSP function also identifies the pseudowire
that is associated with the attachment circuit over which the packet
arrived. If, for example, the packet arrived on a VLAN tagged port,
and the VLAN tag identifies the attachment circuit, then the In-NSP
is responsible for recovering the VLAN tag and identifying the
attachment circuit. It is out of the scope of this document to
define how attachment circuits are represented and associated with
pseudowires.
The resulted Ethernet frame, as delivered by the In-NSP is not
modified in any way by the In-PW function. The In-PW termination
simply imposes the PW encapsulation for the packet. This may be
introducing the optional control word and its fields, depending on
how the pseudowire was configured and which options were negotiated.
Following this step, the PW label for the packet is imposed.
Subsequently, the appropriate forwarding engine component imposes
the PSN encapsulation. How the PSN encapsulation is determined and
imposed for a particular pseudowire is out of the scope of this
document.
Once the packet is delivered to the network, the PSN encapsulation
directs the packet towards the egress endpoint of the pseudowire.
At the egress, the PSN encapsulation is removed. Following this,
the packet is delivered to the Out-PW termination function. The
Out-PW function removes the PW encapsulation. This involves
removing both the PW label and the optional control word (if
negotiated and present). In addition, the PW label is used to
identify an Out-NSP function associated with one or more attachment
circuit(s) that is/are the outgoing interface(s) to the customer.
The packet is handed to the Out-NSP function which will complete
processing and hand the packet to the egress attachment circuit.
The Out-NSP function has the responsibility for processing the
packet in order to prepare it for the egress attachment circuit.
This would involve, e.g., the insertion, deletion or replacement of
different Ethernet tags or other Ethernet encapsulation so that it
can accommodate different types of ACs, for example port, tagged
V. Kompella Expires January 2009 [Page 5]
Internet-Draft Generalized Ethernet Pseudowire July 2008
with one VLAN, tagged with multiple VLANs (QinQ [802.1ad]) or PBB I-
tags.
There are a number of functions that are out of the scope of this
specification. The primary reason they are out of scope is that
they are implementation dependent, and do not relate to the standard
definition of the Generalized Ethernet Pseudowire (GE-PW). For
example, whether the incoming attachment circuit has a pointer to
the In-NSP function or an index into a table, or how the pseudowire
is identified within the forwarding engine are not material to the
definition of the GE-PW. The definition of what the NSP function has
to perform is also a matter of local configuration.
4. Control Plane
All the PW Setup and Maintenance procedures described in [RFC4447]
apply to the GE-PW. There is no need for a new PW type. The Ethernet
type (0x0005) may be used [IANA PWE3] as the new GE-PW procedures
are backwards compatible with an existing implementation using
Ethernet type PW - see section 6. The function of an Ethernet tagged
PW can be also emulated in the NSPs with a GE-PW.
There might be some network scenarios where the required NSP
capabilities need to be signaled between PEs. This might be the case
for certain implementations that need to know what kind of NSP they
need to instantiate for certain PW. Also in some scenarios the
Service Providers might need to make sure the capabilities of the
related NSPs match.
An optional NSP capabilities sub-TLV for the Interface Parameters
TLV [RFC4447] is defined to allow the signaling of NSP capabilities
between Layer 2 PEs.
The NSP Capabilities sub-TLV is included in the related LDP messages
for PW setup and maintenance if the transmitting PE needs to verify
that the remote NSP is capable of performing certain functionality.
On reception of the NSP Capabilities sub-TLV a Layer 2 PE MUST
reject the PW Setup if it does not support or if the related NSP is
not properly configured to support any of the required NSP
capabilities. If the Layer 2 PE does not understand the NSP
Capabilities sub-TLV, it should continue the processing of the
interface parameters while silently discarding the unknown interface
parameter as per [RFC4447] section 5.5.
The format of the NSP sub-TLV follows the standard format defined
for all Interface Parameter sub-TLVs [RFC4447]:
0 1 2 3
V. Kompella Expires January 2009 [Page 6]
Internet-Draft Generalized Ethernet Pseudowire July 2008
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLV Type | Sub-TLV Length | Capability 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Capability 1 (cont) |
| " |
| Capability n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The type for NSP Capabilities sub-TLV is to be assigned by IANA
(0x0D to be confirmed). The following field defines the value length
in octets. Next is one or a list of NSP capabilities.
Each Capability is coded as 1 byte code point followed by an 1 byte
length field (length of the capability parameters in octets)whereas
the rest of the value field is used to indicate parameters specific
to the required capability ID.
The following code points are defined in this document:
- 001, Service delimiting VLAN tag required; length = 2 octets,
value identifies the (tag) Ethernet type (e.g. IEEE 802.1q,
802.1ad, 802.1ah)
- 002, Tag rewrite; length - 2 octets; value identifies the (tag)
Ethernet type, same as for the above
Addditional code points for the NSP Capabilities are to be added as
the applications are being defined.
5. The Control Word
The OPTIONAL control word specified in [RFC4385] MAY be used for the
GE-PW.
6. Backwards Compatibility with existing Ethernet PW implementations
The NSP of a GE-PW capable PE that needs to interoperate with older
implementations may be manually configured to fully emulate the
behavior of an existing Ethernet PW NSP as described in section 4.1
and 4.4 of [RFC4448].
The NSP Capabilities sub-TLV may be also used to automatically
identify the old Ethernet PW implementation. The GE-PW capable PE
may use the received NSP Capabilities indication to identify the
regular (Ethernet or Ethernet VLAN) PW implementations.
The GE-PW capable PE MUST always include the NSP capability sub-TLV
in the PW setup message. If the PW signaling received from the
remote PE does not contain the NSP Capability sub-TLV, the local PE
switches to regular PW mode. If the other Layer 2 PE does not
V. Kompella Expires January 2009 [Page 7]
Internet-Draft Generalized Ethernet Pseudowire July 2008
understand the NSP Capabilities sub-TLV, it should continue the
processing of the interface parameters while silently discarding the
unknown interface parameter as per [RFC4447] section 5.5.
7. Emulating existing Ethernet Services
The rationale for redefining the two variants of the Ethernet
pseudowires is that the GE-PW is a more powerful construct that
subsumes both of them, prevents the future proliferation of other
Ethernet PW types and allows the definition of many more services
than are allowed by strictly following the existing pseudowire
definitions.
The following examples demonstrate that the right set of NSP and PW
functions yield not just the known VPWS, VPLS behaviors induced by
the two existing Ethernet pseudowires, but additional models used by
service providers, that are not strictly compliant to the existing
pseudowires.
7.1. GE-PW applicability to Ethernet PW
The GE-PW allows for emulation of an Ethernet point-to-point service
between different types of Ethernet Attachment Circuits by simply
emulating in the ingress NSP the required behavior. Specifically the
attachment circuits (ACs) may be defined at the PEs to represent the
whole port, one or more VLAN(s) (tagged, one service delimiting
VLAN) or a VLAN combination (QinQ/[802.1ad], tagged with two service
delimiting VLANs) and are mapped to the point-to-point NSP function
in each PE through local association.
As a result the packet arriving on the local AC is classified as
belonging to an ingress NSP who may be configured to
remove/rewrite/add one or more VLAN tags before forwarding the
packet to the GE-PW termination function that will encapsulate it
for transport over PSN core.
Similarly the egress NSP can manipulate encapsulation received over
GE-PW, adding, replacing or removing one or more tags of different
types as desired to accommodate different types of egress Ethernet
interfaces and AC definitions, for example port, tagged with one
VLAN, tagged with multiple VLANs (QinQ [802.1ad]).
A default behavior for the AC processing function of the NSPs
corresponding to the Ethernet PW type can be defined as follows:
- Assume one or more service delimiting tags are used by one of
the NSPs (NSP1) to identify the AC. The other NSP (NSP2) might
use a different set of service delimiting tags to identify the
AC.
V. Kompella Expires January 2009 [Page 8]
Internet-Draft Generalized Ethernet Pseudowire July 2008
- If a packet arrives at NSP1, the related in-NSP AC function
removes the service delimiting tags after AC identification
then performs the rest of the operations as described above.
- At the NSP2, the corresponding out-NSP AC function adds for
each AC the local service delimiting tags.
- This default behavior provides flexibility of supporting
interworking between any kind of ACs without one PE needing to
know what the remote PEs is using for AC identification.
7.2. GE-PW Applicability to Ethernet VLAN PW
Starting from the default behavior outlined in the previous section
for GE-PW, one can emulate the Ethernet VLAN mode by simply
configuring the in-NSP to insert a service delimiting VLAN tag
before sending the packet to the in-PW processing function.
Alternatively the need for service delimiting VLAN tag can be
indicated from the egress PE via the NSP capability TLV using code
point 001 as described in the Control Plane section. The type of tag
to be inserted (IEEE 802.1q, IEEE 802.1ad or proprietary) can be
specify in the parameter field of the capability.
7.3. GE-PW Applicability to VPWS and VPLS
The GE-PW can be used to serve the interconnect needs for the VPWS
and VPLS Forwarders. The previous section discussed how the GE-PW
can replace the existing Ethernet PW types from a point to point
forwarding perspective, handling also the VLAN tags on a per local
AC basis.
VPWS is really a collection of point-to-point virtual circuits, each
of them built as an individual PW context with full (in-NSP, in-PW,
out-PW, out NSP) functions. As demonstrated in the previous two
sections the GE-PW construct can emulate either of the existing
behaviors (Ethernet or Ethernet VLAN PWs) for each of the individual
virtual circuits, providing this way full support for any possible
VPWS combination supported by the existing PW types.
For VPLS the NSPs will have to replicate the same in-NSP AC, out-NSP
AC functions but for multiple ACs, handling also the Ethernet
switching functions (e.g. MAC switching, MAC Learning, Packet
Replication) as described in [RFC4664] and [RFC4762]. Translating
the default behavior for the Ethernet PW type that means each in-NSP
will remove the tags configured for AC identification and each out-
NSP will add the tags configured for AC identification providing
flexible support for any AC combination in the same VPLS.
V. Kompella Expires January 2009 [Page 9]
Internet-Draft Generalized Ethernet Pseudowire July 2008
7.4. GE-PW for point-to-point transport of PBB over Pseudowires
When a PW interconnects two PBB access networks (see Figure 1),
there may be a need to use the PBB ISID Tag (I-tag) [802.1ah] to
perform the mapping to/from ACs. The PBB I-tag can be processed as
an extended tag that may need to be changed at ingress / egress PE.
The related NSPs of a GE-PW can be configured to identify the I-tag
(using the Ethernet type assigned by [802.1ah]) and to change
different I-tag fields, for example the 24 bits ISID or the QoS
information as required. Alternatively the NSP capability code point
002 can be used to indicate the required rewrite of the I-tag fields
for an out-NSP that can not perform this sort of processing. The
parameter value of the code point 002 will specify the Ethernet type
for I-tag [802.1ah].
The GE-PW (in-PW or out-PW) termination functions will not need to
change to accommodate this new type of service. The required PW
encapsulation described in the previous sections will be added
before the PBB Backbone MAC header.
For example assuming the PE depicted in Figure 1 [RFC4448] is
connected to a PBB network (PBBN) and the I-tag field is used to
defined the AC.
+------------------------------------------+
| PE |
+---+ +-+ +-----+ +------+ +------+ +-+
| | |P| | | |PW ter| | PSN | |P|
| |<==|h|<=| NSP |<=|minati|<=|Tunnel|<=|h|<== From PSN
| | |y| | | |on | | | |y|
| P | +-+ +-----+ +------+ +------+ +-+
| B | | |
| B | +-+ +-----+ +------+ +------+ +-+
| N | |P| | | |PW ter| | PSN | |P|
| |==>|h|=>| NSP |=>|minati|=>|Tunnel|=>|h|==> To PSN
| | |y| | | |on | | | |y|
+---+ +-+ +-----+ +------+ +------+ +-+
| |
+------------------------------------------+
Figure 1: PBB/PW
The ingress PE may be configured to check on the incoming PBB
packets the ISID value of the I-tag to determine the AC and
subsequently the ingress NSP. The ingress NSP may be configured to
change the values of different I-tag fields (for example the ISID,
PCP, DEI bits).
V. Kompella Expires January 2009 [Page 10]
Internet-Draft Generalized Ethernet Pseudowire July 2008
Next the GE-PW termination functions will handle the PW header that
will transport it throughout the PSN core and towards the egress
NSP.
The egress NSP may perform different functions depending on the type
of egress AC: e.g.
- if the access network is part of a different PBB service domain
it may re-write the I-tag field.
- if the access domain is a QinQ domain it may remove the PBB
header altogether assuming it supports this capability.
7.5. PBB-VPLS Applicability
The GE-PWs can be also applied to provide the interconnect between
PBB-VPLS entities as described in [PBB-VPLS]. On top of the I-tag
identification, processing functions described in the previous
section, the related NSPs can emulate the PBB components described
in [802.1ah], for example the Backbone (B) and Customer (I)
components. For example, in a PBB-VPLS PE, as the In-NSP function
receive the packet on the local AC, it may remove (default behavior)
the service tags configured locally for each AC identification. Then
it performs the Customer MAC switching and possibly the mapping to
the Backbone MAC address specific to the I-component [802.1ah].
Subsequently the same In-NSP function will perform the Backbone MAC
switching function characteristic to the B-component [802.1ah]. If
the packet is to be transported over the PW infrastructure it will
be handled to the in-PW function as per [PBB-VPLS]. From now on the
processing steps described in the previous sections for various
types of PW behaviors apply. Same for the Out-PW termination
function in the other PE. The PW service label is used by the Out-PW
function to identify the Out-NSP to which the packet is handled.
There are two possibilities for the Out-NSP.
If the PE is the final termination point for PBB, the Out-NSP runs
both I and B components (PBB BEB node in [802.1ah]). It will handle
first the Ethernet switching functions for Backbone MAC header
followed by the switching functions for Customer MAC header. As the
packet is handled to the egress AC the regular AC processing
functions described in the previous sections apply. As a default
behavior the out-NSP will add the service tags configured locally
for AC identification.
If an HVPLS architecture is used the next PE in the chain may be
just an intermediate switching point for Backbone MAC header. The
related Out-NSP function runs just the PBB B-component (PBB BCB node
in [802.1ah]). It will handle just the Ethernet switching functions
for Backbone MAC header. The possible results may be switching the
packet back to another In-PW function for further forwarding towards
the PBB-VPLS PE (PBB BEB).
V. Kompella Expires January 2009 [Page 11]
Internet-Draft Generalized Ethernet Pseudowire July 2008
[PBB-VPLS] and [PBB-Interop] describe the requirements,
interoperability and solution in detail.
Other applications are possible and require just the definition of
the required NSP functions.
8. Management Model
There will be a new object to describe the NSP compatibility
capabilities [PW MIB].
9. Acknowledgements
The authors gratefully acknowledge the contributions of Nabil Bitar,
and Dimitri Papadimitriou.
10. References
Normative References
[RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and
G. Heron, "Pseudowire Setup and Maintenance Using the Label
Distribution Protocol (LDP)", RFC 4447, April 2006.
[RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron,
"Encapsulation Methods for Transport of Ethernet over MPLS
Networks", RFC 4448, April 2006.
[IANA PWE3] Martini, L., "IANA Allocations for Pseudowire Edge to
Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
[RFC4385] Bryant, S., Swallow, G., and D. McPherson, "Pseudowire
Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS
PSN", RFC 4385, February 2006.
[RFC4720] Malis, A., Allan, D.,and N. Del Regno, "Pseudowire
Emulation Edge-to-Edge (PWE3) Frame Check Sequence Retention", RFC
4720, November 2006
[802.1ad] IEEE 802.1ad-2005 "Virtual Bridged Local Area Networks,
Amendment 4: Provider Bridges", December 7, 2005
[802.1ah] IEEE Draft P802.1ah/D4.2 "Virtual Bridged Local Area
Networks, Amendment 6: Provider Backbone Bridges", Work in Progress,
March 26, 2008
V. Kompella Expires January 2009 [Page 12]
Internet-Draft Generalized Ethernet Pseudowire July 2008
[RFC4762] Lasserre, M. and Kompella, V. (Editors), "Virtual Private
LAN Service (VPLS) Using Label Distribution Protocol (LDP)
Signaling", RFC 4762, January 2007.
[PW MIB] T. Nadeau, and D. Zelig "Pseudowire (PW) Management
Information Base (MIB)", draft-ietf-pwe3-pw-mib-14.txt, January 2008
( work in progress ).
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Informative References
[RFC4664] Andersson, L. and Rosen, E. (Editors),"Framework for Layer
2 Virtual Private Networks (L2VPNs)", RFC 4664, September 2006.
[PBB-VPLS] F. Balus, et Al. "VPLS Extensions for Provider Backbone
Bridging", draft-balus-l2vpn-vpls-802.1ah-03.txt, February 2008 (
work in progress ).
[PBB-Interop] A. Sajassi, et Al. "VPLS Interoperability with
Provider Backbone Bridges", draft-sajassi-l2vpn-vpls-pbb-interop-
03.txt, November 2007 ( work in progress ).
11. Security Considerations
No new security issues arise out of the extensions proposed here.
12. IANA Considerations
A new IANA allocation is required to describe NSP compatibility
capabilities.
13. Authors' Addresses
Andrew Malis
Verizon
andrew.g.malis@verizon.com
Giles Heron
British Telecom
giles.heron@bt.com
Shane Amante
Level 3
V. Kompella Expires January 2009 [Page 13]
Internet-Draft Generalized Ethernet Pseudowire July 2008
shane@castlepoint.net
Vach Kompella
Alcatel-Lucent
vach.kompella@alcatel-lucent.com
Florin Balus
Alcatel-Lucent
florin.balus@alcatel-lucent.com
14. Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
15. Intellectual Property
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.
V. Kompella Expires January 2009 [Page 14]
Internet-Draft Generalized Ethernet Pseudowire July 2008
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.
16. Acknowledgments
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
V. Kompella Expires January 2009 [Page 15]