Wildcard Pseudowire Type
RFC 4863
|
| Document |
Type |
|
RFC - Proposed Standard
(May 2007; No errata)
|
|
Last updated |
|
2015-10-14
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
pdf
html
bibtex
|
|
Reviews |
|
|
| Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
| IESG |
IESG state |
|
RFC 4863 (Proposed Standard)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
Mark Townsley
|
|
Send notices to |
|
(None)
|
Network Working Group L. Martini
Request for Comments: 4863 G. Swallow
Category: Standards Track Cisco Systems, Inc.
May 2007
Wildcard Pseudowire Type
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
Pseudowire signaling requires that the Pseudowire Type (PW Type) be
identical in both directions. For certain applications the
configuration of the PW Type is most easily accomplished by
configuring this information at just one PW endpoint. In any form of
LDP-based signaling, each PW endpoint must initiate the creation of a
unidirectional LSP. In order to allow the initiation of these two
LSPs to remain independent, a means is needed for allowing the PW
endpoint (lacking a priori knowledge of the PW Type) to initiate the
creation of an LSP. This document defines a Wildcard PW Type to
satisfy this need.
Table of Contents
1. Introduction ....................................................2
1.1. Conventions and Terminology ................................2
2. Wildcard PW Type ................................................3
3. Procedures ......................................................3
3.1. Procedures When Sending the Wildcard FEC ...................3
3.2. Procedures When Receiving the Wildcard FEC .................3
4. Security Considerations .........................................4
5. IANA Considerations .............................................4
6. References ......................................................4
6.1. Normative References .......................................4
6.2. Informative References .....................................4
Martini & Swallow Standards Track [Page 1]
RFC 4863 Wildcard Pseudowire Type May 2007
1. Introduction
Pseudowire signaling requires that the Pseudowire Type (PW Type) be
identical in both directions. For certain applications the
configuration of the PW Type is most easily accomplished by
configuring this information at just one PW endpoint. In any form of
LDP-based signaling, each PW endpoint must initiate the creation of a
unidirectional LSP.
By the procedures of [CONTROL], both Label Mapping messages must
carry the PW type, and the two unidirectional mapping messages must
be in agreement. Thus within the current procedures, the PW endpoint
that lacks configuration must wait to receive a Label Mapping message
in order to learn the PW Type, prior to signaling its unidirectional
LSP.
For certain applications this can become particularly onerous. For
example, suppose that an ingress Provider Edge (PE) is serving as
part of a gateway function between a layer 2 network and layer 2
attachment circuits on remote PEs. Suppose further that the initial
setup needs to be initiated from the layer 2 network, but the layer 2
signaling does not contain sufficient information to determine the PW
Type. However, this information is known at the PE supporting the
targeted attachment circuit.
In this situation, it is often desirable to allow the initiation of
the two LSPs that compose a pseudowire to remain independent. A
means is needed for allowing a PW endpoint (lacking a priori
knowledge of the PW Type) to initiate the creation of an LSP. This
document defines a wildcard PW Type to satisfy this need.
1.1. Conventions and Terminology
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 [KEYWORDS].
This document introduces no new terminology. However, it assumes
that the reader is familiar with the terminology contained in
[CONTROL] and RFC 3985, "Pseudo Wire Emulation Edge-to-Edge (PWE3)
Architecture" [ARCH].
Martini & Swallow Standards Track [Page 2]
RFC 4863 Wildcard Pseudowire Type May 2007
Show full document text