One document matched: draft-martini-pwe3-status-aggregation-protocol-01.txt
Differences from draft-martini-pwe3-status-aggregation-protocol-00.txt
Internet Engineering Task Force Luca Martini
Internet Draft George Swallow
Intended status: Standards Track Cisco
Expires: April 25, 2011
October 25, 2010
MPLS LSP PW status refresh reduction for Static Pseudowires
draft-martini-pwe3-status-aggregation-protocol-01.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 25, 2010
Abstract
This document describes a method includes generating an aggregated
pseudowire status message on Multi-Protocol Label Switching (MPLS)
network Label Switched Path (LSP). The method for transmitting the
pseudowire (PW) status information is not new, however these protocol
extension allows a Service Provider (SP) to reliably use the PW
static status messages on individual PWs. The aggregated pseudowire
status message configured to verify a current status of all
pseudowires on the LSP.
Martini & Swallow [Page 1]
Internet Draftdraft-martini-pwe3-status-aggregation-protocol-01.txtctober 25, 2010
Table of Contents
1 Specification of Requirements ........................ 2
2 Introduction ......................................... 2
2.1 Terminology .......................................... 3
3 PW status refresh reduction protocol ................. 3
3.1 Protocol states ...................................... 4
3.1.1 INACTIVE ............................................. 4
3.1.2 STARTUP .............................................. 4
3.1.3 ACTIVE ............................................... 4
3.2 Timer value change transition procedure .............. 4
4 PW status refresh reduction Message .................. 5
4.1 PW status refresh reduction TLVs ..................... 6
4.1.1 MPLS-TP Tunnel ID .................................... 6
4.1.2 Static MPLS ID TLV ................................... 6
4.1.3 PW ID List ........................................... 7
5 PW status, and PW provisioning verification procedure ....7
6 PW status and PW status refresh procedure ........... 7
7 Security Considerations .............................. 7
8 IANA Considerations .................................. 7
9 References ........................................... 7
9.1 Normative References ................................. 7
9.2 Informative References ............................... 8
10 Author's Addresses ................................... 8
1. Specification of Requirements
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].
2. Introduction
When PWs use an Multi Protocol Label Switched (MPLS) network as the
Packet Switched Network (PSN), are setup according to [RFC4447]
static configuration mode, the PW status information is propagated
using the method described in [PW-STATUS]. There are 2 basic modes of
operation described in [PW-STATUS] section 5.3: Periodic
retransmission of non-zero status messages, and a simple acknowledge
of PW status (sec 5.3.1 of [PW-STATUS]). The LSP level protocol
described below applies to the case then Pw status is acknowledged
Martini & Swallow [Page 2]
Internet Draftdraft-martini-pwe3-status-aggregation-protocol-01.txtctober 25, 2010
immediately with a requested refresh value of zero. (no refresh) In
this case the PW status refresh reduction protocol is necessary for
several reasons , such as:
-i. Greatly increase the scalability of the PW status protocol
by reducing the amount of messages that a PE needs to
periodically send to it's neighbors.
-ii. Detect a remote PE restart.
-iii. If the local state is lost for some reason, the PE needs to
be able to request a status refresh from the remote PE
-iv. Optionally detect a remote PE provisioning change.
2.1. Terminology
FEC: Forwarding Equivalence Class
LDP: Label Distribution Protocol
LSP: Label Switching Path
MS-PW: Multi-Segment Pseudowire
PE: Provider Edge
PW: Pseudowire
SS-PW: Single-Segment Pseudowire
S-PE: Switching Provider Edge Node of MS-PW
T-PE: Terminating Provider Edge Node of MS-PW
3. PW status refresh reduction protocol
PW status refresh reduction protocol consists of a simple message
that is sent at the LSP level using the MPLS Generic Associated
Channel.
A PE using the PW status refresh reduction protocol MUST send the PW
status refresh reduction Message as soon as a PW is configured on a
particular LSP. The message is then re-transmitted at a locally
configured interval indicated in the refresh timer field. If no
acknowledgment is received, the protocol does not reach active state,
and the PE SHOULD NOT send any PW status messages with a refresh
timer of zero as described in [PW-STATUS] section 5.3.1.
Martini & Swallow [Page 3]
Internet Draftdraft-martini-pwe3-status-aggregation-protocol-01.txtctober 25, 2010
3.1. Protocol states
The protocol can be in 3 possible states: INACTIVE, STARTUP, and
ACTIVE.
3.1.1. INACTIVE
This state is entered when the protocol is turned off. this state is
entered if all PW on a specific LSP are unprovisioned, or the feature
is unprovisioned.
3.1.2. STARTUP
In this state the PE transmits periodic PW status refresh messages,
with the Ack Session ID set to 0. The PE remains in this state until
a PW status refresh message is received with the correct local
session ID in the Ack Session ID Field. This state can be exited to
the ACTIVE or INACTIVE state.
3.1.3. ACTIVE
This state is entered once the PE receives a PW status refresh
message with the correct local session ID in the Ack Session ID Field
within 3.5 times the refresh timer field value of the last PW status
refresh message transmitted. This state is immediately exited as
follows:
-i. A valid PW status refresh message is not received within 3.5
times the current refresh timer field value. (assuming a
timer transition procedure is not in progress) New state:
STARTUP
-ii. A PW status refresh message is received with the wrong, or a
zero value, Ack Session ID field value. New state: STARTUP
-iii. All PWs using the particular LSP are unprovisioned, or the
protocol is disabled. New state: INACTIVE
3.2. Timer value change transition procedure
If a PE needs to change the refresh timer value field while the PW
refresh reduction protocol is in the ACTIVE state, the following
procedure must be followed:
Martini & Swallow [Page 4]
Internet Draftdraft-martini-pwe3-status-aggregation-protocol-01.txtctober 25, 2010
-i. A PW status refresh message is transmitted with the new
timer value.
-ii. If the new value is greater then the original one the PE
will operate on the new timer value immediately.
-iii. If the new value is smaller then the original one, the PE
will operate according to the original timer value for a
period 3.5 times the original timer value, or until the
first valid PW status refresh message is received.
A PE receiving a PW status refresh message with a new timer
value, will immediately transmit an acknowledge PW status
refresh message, and start operating according to the new
timer value.
4. PW status refresh reduction Message
The packet containing the refresh reduction message is constructed as
follows: (omitting link layer information)
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS LSP (tunnel) Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GAL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version| Reserved | 0xZZ PW OAM Message |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Refresh Timer | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Total TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Variable Length Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ PE Information TLVs ~
| Continued |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This message contains the following fields:
* Session ID
A non-zero, locally selected session number that is not preserved
if the local PE restarts.
Martini & Swallow [Page 5]
Internet Draftdraft-martini-pwe3-status-aggregation-protocol-01.txtctober 25, 2010
* Ack Session ID
The Session ID received from the remote PE.
* Refresh Timer.
A value, in seconds, that indicates the desired refresh interval.
* Total TLV Length
Total length in octets of the TLVs. A value of zero means no TLVs
are following.
* TLV Type
The Type of the value that follows. Types are allocated in this
document, and by IANA.
* TLV Length
Length of the value field of the TLV. A value of Zero means an
empty TLV.
* PE Information TLVs
A set of one or more TLVs that contain information about the
local PE.
4.1. PW status refresh reduction TLVs
The PW status refresh reduction TLVs are informational TLVs, that
allow the remote PE to verify certain provisioning information.
4.1.1. MPLS-TP Tunnel ID
This TLV MUST always be present , and contains the address of the
MPLS-TP tunnel ID.
4.1.2. Static MPLS ID TLV
The PE address of the Local PE.
Martini & Swallow [Page 6]
Internet Draftdraft-martini-pwe3-status-aggregation-protocol-01.txtctober 25, 2010
4.1.3. PW ID List
This OPTIONAL TLV contains a list of the provisioned PWs on the LSP.
[ editor's note: extensive procedures TBD ]
5. PW status, and PW provisioning verification procedure
TBD [ editor's note: usage, and procedures for the PW ID List TLV ]
6. PW status and PW status refresh procedure
TBD [ editor's note: local PE behavior for PW status transmittal in
ACTIVE/STARTUP/INACTIVE state]
7. Security Considerations
TBD
8. IANA Considerations
Setup a new registry , of PW status refresh reduction TLVs. ( to be
specified in a future version )
9. References
9.1. Normative References
[RFC2119] Bradner. S, "Key words for use in RFCs to
Indicate Requirement Levels", RFC 2119, March, 1997.
[RFC4447] "Transport of Layer 2 Frames Over MPLS", Martini, L.,
et al., rfc4447 April 2006.
[ON DEMAND] Bahadur et.al. "MPLS on-demand Connectivity
Verification, Route Tracing and Adjacency Verification",
draft-ietf-mpls-tp-on-demand-cv-01.txt, IETF Work in Progress,
October 2010
[PW-STATUS]
L. Martini, G. Swallow, G. Heron, M. Bocci "Pseudowire
Status for Static Pseudowires",
draft-ietf-pwe3-static-pw-status-01.txt, (work in progress),
October 2010
Martini & Swallow [Page 7]
Internet Draftdraft-martini-pwe3-status-aggregation-protocol-01.txtctober 25, 2010
9.2. Informative References
[RFC5586] M. Bocci, Ed., M. Vigoureux, Ed., S. Bryant, Ed.,
"MPLS Generic Associated Channel", rfc5586, June 2009
10. Author's Addresses
Luca Martini
Cisco Systems, Inc.
9155 East Nichols Avenue, Suite 400
Englewood, CO, 80112
e-mail: lmartini@cisco.com
George Swallow
Cisco Systems, Inc.
300 Beaver Brook Road
Boxborough, Massachusetts 01719
United States
e-mail: swallow@cisco.com
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Expiration Date: April 2011
Martini & Swallow [Page 8]
| PAFTECH AB 2003-2026 | 2026-04-20 14:10:45 |