Internet DRAFT - draft-zhang-pwe3-gid-app
draft-zhang-pwe3-gid-app
PWE3 Working Group Haiyan Zhang
Internet Draft Eric Li
Jixiong Dong
Yang Yang
Huawei
Expires: August 2006 February 17, 2006
Pseudowire Group ID Application
draft-zhang-pwe3-gid-app-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 August 17, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006). All Rights Reserved.
Abstract
The Pseudowire Group ID is introduced and simply defined in [PWE3-
CTRL], but how to use Pseudowire Group ID has not been definitely
expounded. This document details the applications of Pseudowire Group
ID.
Zhang Expires August 17, 2006 [Page 1]
Internet-Draft draft-zhang-pwe3-gid-app-00.txt February 2006
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.
Table of Contents
1. Introduction................................................2
2. Terminology.................................................3
3. PW Group....................................................3
4. PW Group ID Application......................................3
4.1. PW Group Protection.....................................4
4.1.1. Protection Information.............................6
4.1.2. Monitoring.........................................6
4.1.3. PW Group Setup.....................................7
4.1.3.1. PW Group Setup by Static Provisioning..........7
4.1.3.2. PW Group Setup by Signaling...................8
4.1.4. PW Group Teardown..................................9
4.1.5. PW Group Protection Behavior......................10
5. Security Considerations.....................................10
6. IANA Considerations........................................10
7. Acknowledgments............................................10
8. References.................................................10
8.1. Normative References...................................10
8.2. Informative References.................................11
9. Author's Addresses.........................................11
10. Intellectual Property Statement............................12
Disclaimer of Validity........................................12
Copyright Statement...........................................12
Acknowledgment................................................13
1. Introduction
The PW Group ID is introduced in [PWE3-CTRL], and the Group ID field
in the PWid FEC element and the PW Grouping ID TLV in the Generalized
ID FEC element are defined, i.e. an arbitrary 32 bit value which
represents a group of PWs that is used to create groups in the PW
space.
But the application of PW Group ID has not been definitely expounded.
The document describes the further applications of PW Group ID in
detail.
Zhang Expires August 17, 2006 [Page 2]
Internet-Draft draft-zhang-pwe3-gid-app-00.txt February 2006
2. Terminology
The document defines the following additional terms:
- PW Group (PWG). A group of PWs, these PWs have some common
characters such as the same PW endpoints, the same PW type or the
same QoS requirements etc. A group of PWs must have the same Group
ID.
- Working PW Group (W-PWG). The PW Group is used to transmit the
service traffic. The service traffic is switched over to the
protection PW Group when the working PW Group failed.
- Protection PW Group (P-PWG). The PW Group is used to protect the
working PW Group. The service traffic is transmitted by protection
PW Group when the working PW Group failed.
- Protection Group. The collection of the Working PW Groups and the
protection PW Groups that are used to provide extra reliability
for the transport of service traffic signals in the Working PW
Groups.
- Monitored Pseudo Wire (M-PW). A monitored PW in a PWG, and the
attribute and status of the M-PW represents the attribute and
status of the PWG. The PW Group protection switching is initiated
when detecting the fault of M-PW.
3. PW Group
In [PWE3-CTRL], the PW group ID is intended to be used as a port
index or a virtual tunnel index. The Group ID field or the PW
Grouping ID TLV can be used to send "wild card" label withdrawals or
"wild card" status notification messages to remote PEs for all
affected sets of PWs.
In fact, the PW Groups may be composed of one or more, SS-PW or MS-PW
PWs by definite rules, and the PWs in the same PW Group must have the
same PW Group ID. The different rules may be adopted for the
different application.
4. PW Group ID Application
The existing protection mechanism adopts the tunnel protection. But
the defects of PWs can not be detected at tunnel. If the protection
connection of some PW goes wrong, the protection switching from the
working tunnel to the protection tunnel can not prevent the traffic
Zhang Expires August 17, 2006 [Page 3]
Internet-Draft draft-zhang-pwe3-gid-app-00.txt February 2006
loss of this PW. Furthermore, the tunnel protection is not applicable
to the MS-PW.
The PW protection mechanism described in [PWE3-PROTECT] solves the
issue of tunnel protection. But the system must monitor every PW. In
case of large numbers of PWs, the switching speed and the QoS will be
influenced.
Therefore, the PW Group protection is introduced and is implemented
by PW Group ID. One or more typical PWs in a PW Group are monitored.
Not to monitor the tunnel or every PWs, enhance the switching
efficiency and reduce the system burthen.
The following sections detail that PW Group ID is used for the End-
to-End PW Group protection. The other applications of PW Group ID
will be studied in the future.
4.1. PW Group Protection
For PW Group protection, a PW Group (PWG) must consist of PWs that
have the same PW endpoints. The other characters such as the same PW
type, the same QoS requirements and the same path etc, may be added
as the partition factors, but not be required.
The working PWGs (W-PWGs) and corresponding protection PWGs (P-PWGs),
that may have the different Group ID and protection information, are
established between two PW endpoints. According to the detection and
the preference level, the service traffic is switched between the W-
PWGs and the P-PWGs, and the protection and recovery are implemented.
There are several types for the PW Group protection, such as 1:1, 1+1
1:N or M:N architecture, revertive or non-revertive switching etc.
Zhang Expires August 17, 2006 [Page 4]
Internet-Draft draft-zhang-pwe3-gid-app-00.txt February 2006
PWG3
------- ------- -------
| PE5 |--------| PE6 |--------| PE7 |
| |--------| |--------| |
------- ------- -------
|| ||
|| ||
|| ||
------- PWG1 -------
| PE1 |.......................| PE2 |
| |.......................| |
------- -------
|| || ||
|| || ..
|| || ||PWG4
|| || ..
|| || ||
------- PWG2 -------
| PE3 |-----------------------| PE4 |
| |-----------------------| |
------- -------
Figure 1 PW Group Protection
The one or multiple W-PWGs may be protected by the relevant one or
multiple P-PWGs. In Figure 1, there are three PWGs, PWG1, PWG2 and
PWG3 between PE1 and PE2, and the three PWGs compose a protection
group. The PWG1 is W-PWG and consists of two SS-PWs. The PWG2 is P-
PWG and consists of two MS-PWs that transit two S-PEs, PE3 and PE4
along their path. The PWG3 is P-PWG and consisting of two MS-PWs that
transit three S-PEs, PE5, PE6 and PE7 along their path.
The PWs in the W-PWGs and P-PWGs are corresponding one-to-one, and
the corresponding PWs have the same characters such as PW type and
QoS requirements etc. A protection group may be established Group by
Group or according to the corresponding PWs together.
In [PWE3-CTRL], the Group ID must not be required to match in both
directions of a PW, i.e. the PWs are identified only by the PW ID or
Generalized ID FEC element.
But for PWG protection, the PWs are identified by the Group ID field
and PW ID field for PWid FEC, or the PW Grouping ID TLV and
Generalized ID FEC element for Generalized PWid FEC. For example, the
PWs that have the same PW ID and the different Group ID for PWid FEC
are different PWs. Between the two PW endpoints, the normal PWs not
adopting PWG protection must have the different Group IDs with the
PWGs for protection.
Zhang Expires August 17, 2006 [Page 5]
Internet-Draft draft-zhang-pwe3-gid-app-00.txt February 2006
4.1.1. Protection Information
When the fault takes place, the protection information of the PWGs
decided the protection behavior. The protection information includes
the protection preference level, the protection type and scheme etc.
The PWG has the highest preference level is W-PWG. The PWs in the
same PWG must have the same protection information.
Since the PWs are bidirectional, the protection information need be
manually configured or exchanged by signaling between the two PW
endpoints to achieve the consistent with each other for a PWG.
The Protection TLV defined in [PWE3-PROTECT] can be used to exchange
the protection information. But some bits of the TLV must be used to
distinguish the PWG protection from the PW protection. The PWs in the
same PWG must have the same Protection TLV.
Otherwise, a new PWG Protection TLV may be defined to indicate and
exchange the PWG protection information. In this case, the PWs in the
same PWG may have the same or the different Protection TLV and must
have the same PWG Protection TLV.
4.1.2. Monitoring
The status of a PWG can be obtained by monitoring one or more typical
PWs in the PWG. The monitored PWs (M-PWs) in W-PWGs and P-PWGs may be
inconsistent. If the PWs in a PWG have the different path, it is
proposed that there is at least one M-PW in every different path.
The protection switching and recovery may be originated by the status
change or the VCCV messages in M-PWs.
PW status signaling messages are used as the default mechanism for AC
and PW status and defect notification for MPLS PSN. The Status Codes
value allocations in [IANA] are as follows:
Bit Mask Description
0x00000000 - Pseudo Wire Forwarding (clear all failures)
0x00000001 - Pseudo Wire Not Forwarding
0x00000002 - Local Attachment Circuit (ingress) Receive Fault
0x00000004 - Local Attachment Circuit (egress) Transmit Fault
0x00000008 - Local PSN-facing PW (ingress) Receive Fault
Zhang Expires August 17, 2006 [Page 6]
Internet-Draft draft-zhang-pwe3-gid-app-00.txt February 2006
0x00000010 - Local PSN-facing PW (egress) Transmit Fault
The above statuses are periodically conveyed by PW status signaling
messages in M-PWs between the two PW endpoints. When the status
change takes place in either PW endpoint, the status is immediately
conveyed.
LRF status (0x00000008) may be produced by the PW forwarder receive
fault, interface fault of the PW endpoints, or the service layer of
the PW.
LTF status (0x00000010) may be produced by the PW forwarder transmit
fault, interface fault of the PW endpoints, or the service layer of
the PW.
When the PW endpoints detect or be notified of LRF or LTF status in
one or more M-PWs of the W-PWG, and the normal status (0x00000000) in
all M-PWs of the P-PWG, the service will be switched from the W-PWG
to the P-PWG.
The other statuses do not belong to PW status, and can not start the
PWG protection switching.
Optionally, the PW endpoints can negotiate the use of VCCV for fault
detection in M-PW.
The VCCV messages are periodically conveyed in M-PWs between the two
PW endpoints. When the PW endpoints do not receive VCCV messages in
one or more M-PWs of the W-PWG for a defined period of time, and VCCV
messages are normally received in all M-PWs of the P-PWG, the service
will be switched from the W-PWG to the P-PWG.
4.1.3. PW Group Setup
4.1.3.1. PW Group Setup by Static Provisioning
The PWs in a PWG are established with the same Group ID by the
existing SS-PW or MS-PW signaling or static configuration. The
protection information for the W-PWGs and P-PWGs is manually
configured at the two PW endpoints.
The particular protection information includes:
- Protection Mode, specify PW Protection or PWG Protection.
- Protection Type, specify Hot Standby or Warm Standby.
Zhang Expires August 17, 2006 [Page 7]
Internet-Draft draft-zhang-pwe3-gid-app-00.txt February 2006
- Protection Scheme, specify 1:1, 1+1, 1:N or M:N Protection.
- Preference Level, specify the PWGs preference level to determine
the switching preemption behavior.
- Recovery Type, specify revertive or non-revertive.
- M-PWs, specify the PWs to be monitored.
- W-PWGs and P-PWGs, bind the W-PWGs and the P-PWGs into a sigle
protection group by associating the Group IDs of W-PWGs and P-PWGs.
4.1.3.2. PW Group Setup by Signaling
The PWG protection can be implemented by Group ID, and need not
extend the existing PW control and maintenance signaling.
The document details the signaling procedures for 1:1 and 1+1 taking
example for Generalized PWid FEC. The signaling procedures for PWid
FEC are similar. The signaling procedures for 1:N and M:N will be
discussed in the future.
In Figure 1, the PE1 sends the Label Mapping messages to initiate the
setup of the PWs. The Label Mapping message for the corresponding PWs
must have the same PW FEC.
The M-PWs are identified by the initial Label Mapping message with a
Protection TLV, i.e. only the messages of the M-PWs include the
Protection TLV and the messages of the other PWs in the PWG do not
include the Protection TLV. Therefore the M-PWs must be first
established to confirm the protection attribute of the PWG by the
Protection TLV. And the M-PWs in the different PWG must have the
different protection preference level. The corresponding PWGs are
bound together to a protection group by the M-PWs with the same PW
FEC.
The PE2 receives the Label Mapping message.
If the PE2 does not support the Protection TLV, it will silently
ignore the TLV in which the U bit (Unknown message bit) is set and
continue the PW setup procedures, i.e. PE2 will send Label Mapping
message without the Protection TLV to setup the PW in the opposite
direction. But only one PW can be setup per pair of ACs between PE1
and PE2. The PE2 will reply a Label Release message if PE1 send
message to setup the extra PWs.
Zhang Expires August 17, 2006 [Page 8]
Internet-Draft draft-zhang-pwe3-gid-app-00.txt February 2006
If the PE2 detects that a Protection TLV is included in the message,
the protection mechanism should be implemented. If the protection
mode of the Protection TLV indicates the PW protection, the PW
protection should be implemented refer to [PWE3-PROTECT].
Otherwise, the protection mode of the Protection TLV indicates the
PWG protection and the Group ID is new, then a new PWG is established.
The PW is marked as the M-PW and PE2 will send Label Mapping message
with the Protection TLV to setup the PW in the opposite direction. In
this case, if the PW FEC already exists in the other PWG, then the
corresponding PWGs should be bound to a protection group.
If the protection mode of the Protection TLV indicates the PWG
protection, but the Group ID already exists and the PW FEC is new in
the PWG, then the PW will join to the PWG, and the PW is marked as
the M-PW. PE2 will send Label Mapping message with the Protection TLV
to setup the PW in the opposite direction. If the PW FEC already
exists in the PWG, i.e. there exist a PW that has the same Group ID
and PW FEC. Then the Label Mapping message is treated as the update
message for the PW. This instance is applicable to afresh specify the
M-PWs.
If the PE2 detects that a Protection TLV is not included in the
message and the Group ID is new, the PW has not protection
characteristic. PE2 sends the Label Mapping message without the
Protection TLV in opposite direction, and a normal PW will be setup.
If the PE2 detects that the Group ID already exists and the PW FEC is
new in the PWG, then the PW will join to the PWG. PE2 will send Label
Mapping message without the Protection TLV to setup the PW in the
opposite direction. If the PW FEC already exists in the PWG, i.e.
there exist a PW that has the same Group ID and PW FEC. Then the
Label Mapping message is treated as the update message for the PW.
In the above-mentioned procedures, the preference level in Protection
TLV may be specified by the original PE (PE1) or the target PE (PE2).
If specified by the target PE, the preference level field may be set
to a fixed value in the original message and be set to the usable
preference level by target PE in reverse message.
4.1.4. PW Group Teardown
Before all M-PWs in a PWG are deleted, the new one or more M-PWs must
be established by manually configuration or signaling, or the
existing one or more non M-PWs must be afresh specified to the M-PWs
by the manually configuration or Label Mapping message with the
Protection TLV.
Zhang Expires August 17, 2006 [Page 9]
Internet-Draft draft-zhang-pwe3-gid-app-00.txt February 2006
Otherwise, the fault can not be detected by monitoring the M-PWs, and
the protection switching can not be implemented in time, so as to the
service is broken off.
Once all the M-PWs in a PWG are deleted and no M-PWs exist in the PWG,
the PWG may be torn down.
Certainly, the PW Group may be torn down by the "wild card" label
withdrawal message.
4.1.5. PW Group Protection Behavior
When the faults are determined in one or more M-PWs of a W-PWG, and
the M-PWs in the P-PWG are normal, the protection switching takes
place.
After all M-PWs in a W-PWG recovery, it is decided whether the
service will revert back to the W-PWG or not according to the
specific protection mode, Revertive or non-revertive.
When protection switching takes place, if there are multiple P-PWGs,
the service will be switched into the normal P-PWG that has the sub-
highest preference level.
5. Security Considerations
This document describes the applications of the Group ID, and it has
the same security properties as in [PWE3-CTRL].
6. IANA Considerations
This document does not define the new extension, and need not the
assignment by IANA.
7. Acknowledgments
8. References
8.1. Normative References
[PWE3-CTRL] Luca Martini (ED), Toby Smith, "Pseudowire Setup and
Maintenance using the Label Distribution Protocol", draft-
ietf-pwe3-control-protocol-17.txt, June 2005.
Zhang Expires August 17, 2006 [Page 10]
Internet-Draft draft-zhang-pwe3-gid-app-00.txt February 2006
[PWE3-OAM] Thomas D. Nadeau, Monique Morrrow, Peter Busschbach,
Mustapha Aissaoui, "Pseudo Wire (PW) OAM Message Mapping",
draft-ietf-pwe3-oam-msg-map-03.txt, September 2005.
[PWE3-VCCV] T. D. Nadeau (ED), R. Aggarwal (ED), "Pseudo Wire Virtual
Circuit Connectivity Verification (VCCV)", draft-ietf-pwe3-
vccv-07, September 2005.
8.2. Informative References
[PWE3-ARCH] Bryant, S., Pate, P., "PWE3 Architecture", RFC 3985,
March 2004.
[PWE3-REQ] Xiao, X., McPherson, D., Pate, P., "Requirements for
Pseudo Wire Emulation Edge to-Edge (PWE3)", RFC 3916,
January 2004.
[PWE3-PROTECT] Ping Pan, "Pseudo Wire Protection", draft-pan-pwe3-
protection, July 2005.
[IANA] Luca Martini, "IANA Allocations for pseudo Wire Edge to Edge
Emulation (PWE3)", draft-ietf-pwe3-iana-allocation-15,
November 2005.
9. Author's Addresses
Haiyan Zhang
Huawei Technologies Co., Ltd.
Bantian industry base, Longgang district
Shenzhen, China
Email: zhanghaiyan@huawei.com
Eric Li
Huawei Technologies Co., Ltd.
Bantian industry base, Longgang district
Shenzhen, China
Email: xxl@huawei.com
Jixiong Dong
Huawei Technologies Co., Ltd.
Bantian industry base, Longgang district
Shenzhen, China
Email: dongjixiong@huawei.com
Zhang Expires August 17, 2006 [Page 11]
Internet-Draft draft-zhang-pwe3-gid-app-00.txt February 2006
Yang Yang
Huawei Technologies Co., Ltd.
Bantian industry base, Longgang district
Shenzhen, China
Email: healthinghearts@huawei.com
10. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006).
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.
Zhang Expires August 17, 2006 [Page 12]
Internet-Draft draft-zhang-pwe3-gid-app-00.txt February 2006
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Zhang Expires August 17, 2006 [Page 13]
