Network Working Group Praveen Muley
Internet Draft Mustapha Aissaoui
Intended Status: Informational Matthew Bocci
Expires: August 2007 Pranjal Kumar Dutta
Marc Lasserre
Alcatel
Jonathan Newton
Cable & Wireless
Olen Stokes
Extreme Networks
Hamid Ould-Brahim
Nortel
March 5, 2007
Pseudowire (PW) Redundancy
draft-muley-pwe3-redundancy-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of
BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on September 5, 2007.
Abstract
Muley et al. Expires September 5, 2007 [Page 1]
Internet-Draft Pseudowire (PW) Redundancy) March 2007
This document describes few scenarios where PW redundancy is
needed. A set of redundant PWs is configured between PE nodes in SS-
PW applications, or between T-PE nodes in MS-PW applications. In
order for the PE/T-PE nodes to indicate the preferred PW path to
forward to one another, a new status bit is needed to indicate the
preferential forwarding status of active or standby for each PW in
the redundancy set as defined in [7].
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 [1].
Table of Contents
1. Terminology....................................................3
2. Introduction...................................................3
3. Multi-homing Single SS-PW redundancy applications..............4
3.1. One Multi-homed CE with single SS-PW redundancy...........4
3.2. Multiple Multi-homed CEs with single SS-PW redundancy.....6
4. Multi-homing MS-PW redundancy applications.....................7
4.1. Multi-homed CE with MS-PW redundancy......................7
4.2. Single Homed CE with MS-PW redundancy.....................8
5. Multi-homing VPLS applications.................................9
5.1. PW redundancy between MTU-s and PEs.......................9
5.2. PW redundancy between n-PEs..............................10
5.3. PW redundancy in Bridge Module Model.....................11
6. Design considerations.........................................13
7. IANA Considerations...........................................13
8. Security Considerations.......................................13
9. Acknowledgments...............................................14
10. References...................................................14
10.1. Normative References....................................14
10.2. Informative References..................................14
Author's Addresses...............................................14
Intellectual Property Statement..................................15
Disclaimer of Validity...........................................16
Acknowledgment...................................................16
Muley et al. Expires September 5, 2007 [Page 2]
Internet-Draft Pseudowire (PW) Redundancy) March 2007
1. Terminology
o PW Terminating Provider Edge (T-PE). A PE where the customer-
facing attachment circuits (ACs) are bound to a PW forwarder. A
Terminating PE is present in the first and last segments of a MS-
PW. This incorporates the functionality of a PE as defined in
RFC3985 [3].
o Single-Segment Pseudo Wire (SS-PW). A PW setup directly between
two T-PE devices. Each PW in one direction of a SS-PW traverses
one PSN tunnel that connects the two T-PEs.
o Multi-Segment Pseudo Wire (MS-PW). A static or dynamically
configured set of two or more contiguous PW segments that behave
and function as a single point-to-point PW. Each end of a MS-PW by
definition MUST terminate on a T-PE.
o PW Segment. A part of a single-segment or multi-segment PW, which
is set up between two PE devices, T-PEs and/or S-PEs.
o PW Switching Provider Edge (S-PE). A PE capable of switching the
control and data planes of the preceding and succeeding PW
segments in a MS-PW. The S-PE terminates the PSN tunnels of the
preceding and succeeding segments of the MS-PW.
o PW switching point for a MS-PW. A PW Switching Point is never the
S-PE and the T-PE for the same MS-PW. A PW switching point runs
necessary protocols to setup and manage PW segments with other PW
switching points and terminating PEs
o Active PW. A PW whose preferential status is set to Active and
Operational status is UP.
o Standby PW. A PW whose preferential status is set to Standby.
2. Introduction
In single-segment PW (SS-PW) applications, protection for the PW is
provided by the PSN layer. This may be an RSVP LSP with a FRR backup
and/or an end-to-end backup LSP. There are however applications where
the backup PW terminates on a different target PE node. PSN
protection mechanisms cannot protect against failure of the target PE
node or the failure of the remote AC.
In multi-segment PW (MS-PW) applications, a primary and multiple
secondary PWs in standby mode are configured in the network. The
paths of these PWs are diverse and are switched at different S-PE
Muley et al. Expires September 5, 2007 [Page 3]
Internet-Draft Pseudowire (PW) Redundancy) March 2007
nodes. In these applications, PW redundancy is important for the
service resilience.
This document describes these applications and uses a new PW status
bit defined in [7] to indicate the preferential forwarding status of
the PW for the purpose of notifying the remote T-PE of the
active/standby state of each PW in the redundancy set. This status
bit is different from the operational status bits already defined in
the PWE3 control protocol [2]. The PW with both local and remote
operational UP status and local and remote preferential active status
is selected to forward traffic.
3. Multi-homing Single SS-PW redundancy applications
3.1. One Multi-homed CE with single SS-PW redundancy
The following figure illustrates an application of single segment
pseudo-wire redundancy.
|<-------------- Emulated Service ---------------->|
| |
| |<------- Pseudo Wire ------>| |
| | | |
| | |<-- PSN Tunnels-->| | |
| V V V V |
V AC +----+ +----+ AC V
+-----+ | | PE1|==================| | | +-----+
| |----------|....|...PW1.(active)...|....|----------| |
| | | |==================| | | CE2 |
| CE1 | +----+ |PE2 | | |
| | +----+ | | +-----+
| | | |==================| |
| |----------|....|...PW2.(standby)..| |
+-----+ | | PE3|==================| |
AC +----+ +----+
Figure 1 Multi-homed CE with single SS-PW redundancy
In Figure 1, CE1 is dual homed to PE1 and to PE3 by attachment
circuits. The method for dual-homing of CE1 to PE1 and PE3 nodes and
the used protocols such as Multi-chassis Link Aggregation Group (MC-
LAG), are outside the scope of this document. PE2 has an attachment
circuit from CE2. Two pseudo-wires pw1 and pw2 are established, one
connects PE1 to PE2 and the other one connects PE3 to PE2. On PE2,
PW1 has a higher priority than PW2 by local configuration. In case of
MC-LAG Active/Standby status is derived by the Link Aggregation
Muley et al. Expires September 5, 2007 [Page 4]
Internet-Draft Pseudowire (PW) Redundancy) March 2007
Control protocol (LACP) negotiation which is used in determining the
priority of the PW.
In normal operation, PE1 and PE3 will advertise "Active" and
"Standby" preferential forwarding status (apart from operational
status) respectively to PE2. This status reflects the forwarding
state of the two AC's to CE1. PE2 advertises preferential status of
"Active" on both PW1 and PW2. As both the local and remote
operational and administrative status for PW1 are UP and Active,
traffic is forwarded over PW1 in both directions.
On failure of AC to PE1, PE1 sends a PW status notification to PE2
indicating that the AC operational status changed to DOWN. It will
also set the forwarding status of PW1 to "standby". PE3 AC will
change preferential status to active and this status is also
communicated to PE2 using the newly proposed forwarding status bit in
the PW status TLV notification message. The changing of preferential
status on PE3 due to failure of AC at PE1 is achieved by various
methods depending of the used dual-homing protocol and is outside the
scope of this draft. For example the MC-LAG control protocol changes
the link status on PE3 to active. On receipt of the status
notifications, PE2 switches the path to the standby pseudo-wire PW2
as the newly changed status turns PW2 as Active PW. Note in this
example, the receipt of the operational status of the AC on the CE1-
PE1 link is normally sufficient to have PE2 switch the path to PW2.
However, the operator may want to trigger the switchover of the path
of the PW for administrative reasons, i.e., maintenance, and thus the
proposed PW forwarding active/standby bit is required to notify PE2
to trigger the switchover.
Muley et al. Expires September 5, 2007 [Page 5]
Internet-Draft Pseudowire (PW) Redundancy) March 2007
3.2. Multiple Multi-homed CEs with single SS-PW redundancy
|<-------------- Emulated Service ---------------->|
| |
| |<------- Pseudo Wire ------>| |
| | | |
| | |<-- PSN Tunnels-->| | |
| V V V V |
V AC +----+ +----+ AC V
+-----+ | |....|.......PW1........|....| | +-----+
| |----------| PE1|...... .........| PE3|----------| |
| CE1 | +----+ \ / PW3 +----+ | CE2 |
| | +----+ X +----+ | |
| | | |....../ \..PW4....| | | |
| |----------| PE2| | PE4|--------- | |
+-----+ | |....|.....PW2..........|....| | +-----+
AC +----+ +----+ AC
Figure 2 Multiple Multi-homed CEs with single SS-PW redundancy
In the Figure 2 illustrated above both CEs, CE1 and CE2 are dual-
homed with PEs, PE1, PE2 and PE3, PE4 respectively. The method for
dual-homing and the used protocols such as Multi-chassis Link
Aggregation Group (MC-LAG) are outside the scope of this document.
Note that the PSN tunnels are not shown in this figure for clarity.
However, it can be assumed that each of the PWs shown is encapsulated
in a separate PSN tunnel.
PE1 advertises the preferential status "active" and operational
status "UP" for pseudo-wires PW1 and PW4 connected to PE3 and PE4.
This status reflects the forwarding state of the AC attached to PE1.
PE2 advertises preferential status "standby" where as operational
status "UP" for pseudo-wires PW2 and PW3 to PE3 and PE4. PE3
advertises preferential status "standby" where as operational status
"UP" for pseudo-wires PW1 and PW3 to PE1 and PE2. PE4 advertise the
preferential status "active" and operational status "UP" for pseudo-
wires PW2 and PW4 to PE2 and PE1 respectively. The method of
deriving Active/Standby status of the AC is outside the scope of
this document. In case of MC-LAG it is derived by the Link
Aggregation Control protocol (LACP) negotiation. Thus by matching
the local and remote preferential status "active" and operational
status "Up" of pseudo-wire the active pseudo-wire is selected. In
this case it is the PW4 that will be selected.
Muley et al. Expires September 5, 2007 [Page 6]
Internet-Draft Pseudowire (PW) Redundancy) March 2007
On failure of AC between the CE1 and PE1 the
preferential status on PE2 is changed. Different
mechanisms/protocols can be used to achieve this and these are
beyond the scope of this document. For example the MC-LAG control
protocol changes the link status on PE2 to active. PE2 then
announces the newly changed preferential status "active" to PE3 and
PE4. PE1 will advertise a PW status notification message indicating
that the AC between CE1 and PE1 is operationally down. PE2 and PE4
checks the local and remote preferential status "active" and
operational status "Up" and selects PW2 as the new active pseudo-
wire to send traffic.
In this application, because each dual-homing algorithm running on
the two node sets, i.e., {CE1, PE1, PE2} and {CE2, PE3, PE4}, selects
the active AC independently, there is a need to signal the active
status of the AC such that the PE nodes can select a common active PW
path for end-to-end forwarding between CE1 and CE2.
4. Multi-homing MS-PW redundancy applications
4.1. Multi-homed CE with MS-PW redundancy
The following figure illustrates an application of multi-segment
pseudo-wire redundancy.
Native |<-----------Pseudo Wire----------->| Native
Service | | Service
(AC) | |<-PSN1-->| |<-PSN2-->| | (AC)
| V V V V V V |
| +-----+ +-----+ +-----+
+----+ | |T-PE1|=========|S-PE1|=========|T-PE2| | +----+
| |-------|......PW1-Seg1.......|PW1-Seg2.......|-------| |
| | | |=========| |=========| | | |
| CE1| +-----+ +-----+ +-----+ | |
| | |.| +-----+ +-----+ | CE2|
| | |.|===========| |=========| | | |
| | |.....PW2-Seg1......|.PW2-Seg2......|-------| |
+----+ |=============|S-PE2|=========|T-PE4| | +----+
+-----+ +-----+ AC
Figure 3 Muti-homed CE with MS-PW redundancy
In Figure 3, the PEs that provides PWE3 to CE1 and CE2 are
Terminating-PE1 (T-PE1) and Terminating-PE2 (T-PE2) respectively. A
PSN tunnel extends from T-PE1 to switching-PE1 (S-PE1) across PSN1,
and a second PSN tunnel extends from S-PE1 to T-PE2 across PSN2. PW1
and PW2 are used to connect the attachment circuits (ACs) between T-
Muley et al. Expires September 5, 2007 [Page 7]
Internet-Draft Pseudowire (PW) Redundancy) March 2007
PE1 and T-PE2. Each PW segment on the tunnel across PSN1 is switched
to a PW segment in the tunnel across PSN2 at S-PE1 to complete the
multi-segment PW (MS-PW) between T-PE1 and T-PE2. S-PE1 is therefore
the PW switching point. PW1 has two segments and is active pseudo-
wire while PW2 has two segments and is a standby pseudo-wire. This
application requires support for MS-PW with segments of the same type
as described in [6]. The operation in this case is the same as in the
case of SS-PW. The only difference is that the S-PW nodes need to
relay the PW status notification containing both the operational and
forwarding status to the T-PE nodes.
4.2. Single Homed CE with MS-PW redundancy
This is the main application of interest and the network setup is
shown in Figure 4
Native |<------------Pseudo Wire------------>| Native
Service | | Service
(AC) | |<-PSN1-->| |<-PSN2-->| | (AC)
| V V V V V V |
| +-----+ +-----+ +-----+ |
+----+ | |T-PE1|=========|S-PE1|=========|T-PE2| | +----+
| |-------|......PW1-Seg1.......|.PW1-Seg2......|-------| |
| CE1| | |=========| |=========| | | CE2|
| | +-----+ +-----+ +-----+ | |
+----+ |.||.| |.||.| +----+
|.||.| +-----+ |.||.|
|.||.|=========| |========== .||.|
|.||...PW2-Seg1......|.PW2-Seg2...||.|
|.| ===========|S-PE2|============ |.|
|.| +-----+ |.|
|.|============+-----+============= .|
|.....PW3-Seg1.| | PW3-Seg2......|
==============|S-PE3|===============
| |
+-----+
Figure 4 Single homed CE with multi-segment pseudo-wire redundancy
In Figure 4, CE1 is connected to PE1 in provider Edge 1 and CE2 to
PE2 in provider edge 2 respectively. There are three segmented PWs. A
primary PW, PW1, is switched at S-PE1. A standby PW, PW2, which is
switched at S-PE2 and has a priority of 1. Finally, another standby
PW, PW3, is switched at S-PE3 and has a priority of 2. This means T-
PE1 and T-PE2 will select PW1 over PW2, and PW2 over PW3 if all of
them are in the UP state. Moreover, a T-PE node will revert back to
the primary PW, PW1, whenever it comes back up.
Muley et al. Expires September 5, 2007 [Page 8]
Internet-Draft Pseudowire (PW) Redundancy) March 2007
The intent of this application is to have T-PE1 and T-PE2 synchronize
the transmit and receive paths of the PW over the network. In other
words, both T-PE nodes will transmit over the PW segment which is
switched by the same S-PE. This is desirable for ease of operation
and troubleshooting.
Since there is no multi-homing running on the AC, the T-PE nodes
would advertise 'Active" for the forwarding status. However, this
does not guarantee that the paths of the PW are synchronized because
for example of mismatch of the configuration of the PW priority in
each T-PE. Thus, there is a need to devise an augmented mechanism to
achieve the desirable synchronization of the PW paths and to add the
ability to have a T-PE instruct the remote T-PE to perform a
coordinated switchover to a common Active path.
The solution required for this specific scenario is left for further
study.
5. Multi-homing VPLS applications
5.1. PW redundancy between MTU-s and PEs
Following figure illustrates the application of use of PW redundancy
in spoke PW by dual homed MTU-s to PEs.
|<-PSN1-->| |<-PSN2-->|
V V V V
+-----+ +-----+
|MTU-s|=========|PE1 |========
|..Active PW group....| H-VPLS-core
| |=========| |=========
+-----+ +-----+
|.|
|.| +-----+
|.|===========| |==========
|...Standby PW group|.H-VPLS-core
=============| PE2|==========
+-----+
Figure 5 Muti-homed MTU-s in H-VPLS core
In Figure 5, MTU-s is dual homed to PE1 and PE2. The active spoke PWs
from MTU-s are connected to PE1 while the standby PWs are connected
to PE2. PE1 and PE2 are connected to H-VPLS core on the other side of
network. MTU-s communicates the status of its member PWs for a set of
VSIs having common status Active/Standby. It is signaled using PW
grouping with common group-id in PWid FEC Element or Grouping TLV in
Muley et al. Expires September 5, 2007 [Page 9]
Internet-Draft Pseudowire (PW) Redundancy) March 2007
Generalized PWid FEC Element as defined in [2] to PE1 and PE2
respectively, to scale better. MTU-s derives the status of the PWs
based on local policy configuration.
Whenever MTU-s performs a switchover, it sends a
wildcard Notification Message to PE2-rs for the Standby PW group
containing PW Status TLV with PW Standby bit cleared. On receiving
the notification PE-2 unblocks all member PWs identified by the PW
group and state of PW group changes from Standby to Active.
It is to note that in this mechanism unless there is
a failure to unblock PW groups at PE2, always a single wildcard
Notification Message is exchanged per PW group. On failure to unblock
the PW group PE2 may have to send Notifications of the fatal error
per PW as PW grouping is unidirectional as per [2](in this case from
MTU-s to PE2 only).
The status notification defined here is similar to Topology Change
Notification in RSTP controlled IEEE Ethernet Bridges in [8] but
restricted over a single hop. When the mechanism defined in this
document is implemented, PE devices are aware of switchovers at MTU-s
and could generate MAC Withdraw Messages to trigger MAC flushing
within the H-VPLS full mesh. By default, MTU-s devices should still
trigger MAC Withdraw messages as currently defined in [5] to prevent
two copies of MAC withdraws to be sent (one by MTU-s and another one
by PEs). Mechanisms to disable MAC Withdraw trigger in certain
devices is out of the scope of this document.
5.2. PW redundancy between n-PEs
Following figure illustrates the application of use of PW redundancy
for dual homed connectivity between PE devices in a ring topology.
Muley et al. Expires September 5, 2007 [Page 10]
Internet-Draft Pseudowire (PW) Redundancy) March 2007
+-------+ +-------+
| PE1 |=====================| PE2 |====...
+-------+ PW Group 1 +-------+
|| ||
VPLS Domain A || || VPLS Domain B
|| ||
+-------+ +-------+
| PE3 |=====================| PE4 |==...
+-------+ PW Group 2 +-------+
Figure 6 Redundancy in Ring Topology
In Figure 6, PE1 and PE3 from VPLS domain A are connected to PE2 and
PE4 in VPLS domain B via PW group 1 and group 2. Each of the PE in
respective domain is connected to each other as well to form the ring
topology. Such scenarios may arise in inter-domain H-VPLS deployments
where RSTP or other mechanisms may be used to maintain loop free
connectivity of PW groups.
Ref.[5] outlines about multi-domain VPLS service without
specifying how redundant border PEs per domain per VPLS instance can
be supported. In the example above, PW group1 may be blocked at PE1
by RSTP and it is desirable to block the group at PE2 by virtue of
exchanging the PW preferential status as Standby. How the PW grouping
should be done here is again deployment specific and is out of scope
of the solution.
5.3. PW redundancy in Bridge Module Model
Muley et al. Expires September 5, 2007 [Page 11]
Internet-Draft Pseudowire (PW) Redundancy) March 2007
--------------------------+ Provider +------------------------
. Core .
+------+ . . +------+
| n-PE |======================| n-PE |
Provider | (P) |---------\ /-------| (P) | Provider
Access +------+ ._ \ / . +------+ Access
Network . \/ . Network
(1) +------+ . /\ . +------+ (2)
| n-PE |----------/ \--------| n-PE |
| (B) |----------------------| (B) |_
+------+ . . +------+
. .
-------------------------+ +------------------------
Figure 7 Bridge Module Model
In Figure 7, two provider access networks, each having two n-PEs,
where the n-PEs are connected via a full mesh of PWs for a given VPLS
instance. As shown in the figure, only one n-PE in each access
network is serving as a Primary PE (P) for that VPLS instance and the
other n-PE is serving as the backup PE (B).In this figure, each
primary PE has two active PWs originating from it. Therefore, when a
multicast, broadcast, and unknown unicast frame arrives at the
primary n-PE from the access network side, the n-PE replicates the
frame over both PWs in the core even though it only needs to send the
frames over a single PW (shown with == in the figure) to the primary
n-PE on the other side. This is an unnecessary replication of the
customer frames that consumes core-network bandwidth (half of the
frames get discarded at the receiving n-PE). This issue gets
aggravated when there is three or more n-PEs per provider, access
network. For example if there are three n-PEs or four n-PEs per
access network, then 67% or 75% of core-BW for multicast, broadcast
and unknown unicast are respectively wasted.
Muley et al. Expires September 5, 2007 [Page 12]
Internet-Draft Pseudowire (PW) Redundancy) March 2007
In this scenario, Standby PW signaling defined in
[7] can be used among n-PEs that can disseminate the status of PWs
(active or blocked) among themselves and furthermore to have it tied
up with the redundancy mechanism such that per VPLS instance the
status of active/backup n-PE gets reflected on the corresponding PWs
emanating from that n-PE.
6. Design considerations
While using the pseudo-wire redundancy application, the T-LDP peers
MUST negotiate the usage of PW status TLV. The status code defined
below carries the active/standby preferential forwarding status of
the pseudo-wire. The pseudo-wire is only considered active pseudo-
wire only when both the local PW status and the remote PW status
indicate preferential status "active" and operational status as Up.
Any other status combination keeps the pseudo-wire in standby mode.
The pseudo-wires are given different preference level. In case of
network failure, the PE/T-PE will first switch to the standby PW with
a higher preference. Although the configuration of the pseudo-wire
preference is matter of local policy matter and is outside the scope
of this, it is desirable to have the preferences configured on both
end points be similar. In mis-configuration, a method to force the
synchronization of the PW paths is required is for further study.
While in standby status, a pseudo-wire can still receive packets in
order to avoid black holing of the in-flight packets during
switchover.
The application of Standby PWs in VPLS redundancy is OPTIONAL
and is a tradeoff between savings in bandwidth/resources and traffic
switchover time on PW state change from Standby to Active.
Implementations SHOULD provide facilities to administratively enable
or disable this mechanism based on whether the resulting switchover
time is acceptable to SLA between a provider and its customers or
not. The target environment of the current solution is H-VPLS
redundancy scenarios defined in [5] and is equally applicable to
other possible VPLS redundancy scenarios.
7. IANA Considerations
This document does not require any IANA assignments or action.
8. Security Considerations
This document uses the LDP extensions that are needed for protecting
pseudo-wires. It will have the same security properties as in LDP [4]
and the PW control protocol [2].
Muley et al. Expires September 5, 2007 [Page 13]
Internet-Draft Pseudowire (PW) Redundancy) March 2007
9. Acknowledgments
The authors would like to thank Vach Kompella, Kendall Harvey,
Tiberiu Grigoriu, Neil Hart, Kajal Saha, Florin Balus and Philippe
Niger for their valuable comments and suggestions.
10. References
10.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Martini, L., et al., "Pseudowire Setup and Maintenance using
LDP", RFC 4447, April 2006.
[3] Bryant, S., et al., " Pseudo Wire Emulation Edge-to-Edge (PWE3)
Architecture", March 2005
[4] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B.
Thomas, "LDP Specification", RFC 3036, January 2001
[5] Kompella,V., Lasserrre, M. , et al., "Virtual Private LAN
Service (VPLS) Using LDP Signalling", RFC 4762, January 2007
10.2. Informative References
[6] Martini, L., et al., "Segmented Pseudo Wire", draft-ietf-pwe3-
segmented-pw-02.txt, March 2006.
[7] Muley, P. et al., "Preferential forwarding status bit", draft-
muley-dutta-pwe3-redundancy-bit-00.txt, August 2007.
[8] IEEE Std. 802.1D-2003-Media Access Control (MAC) Bridges.
Author's Addresses
Praveen Muley
Alcatel
701 E. Middlefiled Road
Mountain View, CA, USA
Email: Praveen.muley@alcatel.com
Muley et al. Expires September 5, 2007 [Page 14]
Internet-Draft Pseudowire (PW) Redundancy) March 2007
Mustapha Aissaoui
Alcatel
600 March Rd
Kanata, ON, Canada K2K 2E6
Email: mustapha.aissaoui@alcatel.com
Matthew Bocci
Alcatel
Voyager Place, Shoppenhangers Rd
Maidenhead, Berks, UK SL6 2PJ
Email: matthew.bocci@alcatel.co.uk
Pranjal Kumar Dutta
Alcatel-Lucent
Email: pdutta@alcatel-lucent.com
Marc Lasserre
Alcatel-Lucent
Email: mlasserre@alcatel-lucent.com
Jonathan Newton
Cable & Wireless
Email: Jonathan.Newton@cwmsg.cwplc.com
Olen Stokes
Extreme Networks
Email: ostokes@extremenetworks.com
Hamid Ould-Brahim
Nortel
Email: hbrahim@nortel.com
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
Muley et al. Expires September 5, 2007 [Page 15]
Internet-Draft Pseudowire (PW) Redundancy) March 2007
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, 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.
Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Muley et al. Expires September 5, 2007 [Page 16]