Wildcard Pseudowire Type
RFC 4863

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