Wildcard Pseudowire Type
RFC 4863
Document | Type | RFC - Proposed Standard (May 2007; No errata) | |
---|---|---|---|
Authors | Luca Martini , George Swallow | ||
Last updated | 2015-10-14 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Reviews | |||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 4863 (Proposed Standard) | |
Action Holders |
(None)
|
||
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 2. Wildcard PW Type In order to allow a PE to initiate the signaling exchange for a pseudowire without knowing the pseudowire type, a new PW Type is defined. The codepoint is 0x7FFF. The semantics are the following: 1. To the targeted PE, this value indicates that it is to determine the PW Type (for both directions) and signal that in a LabelShow full document text