GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4619

Network Working Group L. Martini, Ed. Request for Comments: 4619 Cisco Systems, Inc. Category: Standards Track C. Kawa, Ed.

                                                     Oz Communications
                                                         A. Malis, Ed.
                                                               Tellabs
                                                        September 2006
      Encapsulation Methods for Transport of Frame Relay over
           Multiprotocol Label Switching (MPLS) Networks

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 Internet Society (2006).

Abstract

 A frame relay pseudowire is a mechanism that exists between a
 provider's edge network nodes and that supports as faithfully as
 possible frame relay services over an MPLS packet switched network
 (PSN).  This document describes the detailed encapsulation necessary
 to transport frame relay packets over an MPLS network.

Martini & Kawa Standards Track [Page 1] RFC 4619 Encapsulation for Transport of Frame Relay September 2006

Table of Contents

 1. Introduction ....................................................2
 2. Specification of Requirements ...................................4
 3. Co-authors ......................................................4
 4. Acronyms and Abbreviations ......................................5
 5. Applicability Statement .........................................5
 6. General Encapsulation Method ....................................6
 7. Frame Relay over MPLS PSN for the One-to-One Mode ...............7
    7.1. MPLS PSN Tunnel and PW .....................................7
    7.2. Packet Format over MPLS PSN ................................7
    7.3. The Control Word ...........................................8
    7.4. The Martini Legacy Mode Control Word .......................9
    7.5. PW Packet Processing .......................................9
         7.5.1. Encapsulation of Frame Relay Frames .................9
         7.5.2. Setting the Sequence Number ........................10
    7.6. Decapsulation of PW Packets ...............................11
         7.6.1. Processing the Sequence Number .....................11
         7.6.2. Processing of the Length Field by the Receiver .....11
    7.7. MPLS Shim EXP Bit Values ..................................12
    7.8. MPLS Shim S Bit Value .....................................12
    7.9. Control Plane Details for Frame Relay Service .............12
         7.9.1. Frame Relay Specific Interface Parameter Sub-TLV ...12
 8. Frame Relay Port Mode ..........................................13
 9. Congestion Control .............................................13
 10. Security Considerations .......................................14
 11. Normative References ..........................................14
 12. Informative References ........................................15

1. Introduction

 In an MPLS or IP network, it is possible to use control protocols
 such as those specified in [RFC4447] to set up "pseudowires" (PWs)
 that carry the Protocol Data Units of layer 2 protocols across the
 network.  A number of these emulated PWs may be carried in a single
 tunnel.  The main functions required to support frame relay PW by a
 Provider Edge (PE) include:
  1. encapsulation of frame relay specific information in a suitable

pseudowire (PW) packet;

  1. transfer of a PW packet across an MPLS network for delivery to a

peer PE;

  1. extraction of frame relay specific information from a PW packet by

the remote peer PE;

Martini & Kawa Standards Track [Page 2] RFC 4619 Encapsulation for Transport of Frame Relay September 2006

  1. regeneration of native frame relay frames for forwarding across an

egress port of the remote peer PE; and

  1. execution of any other operations as required to support frame

relay service.

 This document specifies the encapsulation for the emulated frame
 relay VC over an MPLS PSN.  Although different layer 2 protocols
 require different information to be carried in this encapsulation, an
 attempt has been made to make the encapsulation as common as possible
 for all layer 2 protocols.  Other layer 2 protocols are described in
 separate documents.  [ATM] [RFC4448] [RFC4618]
 The following figure describes the reference models that are derived
 from [RFC3985] to support the frame relay PW emulated services.
       |<-------------- Emulated Service ---------------->|
       |                                                  |
       |          |<------- Pseudowire ------->|          |
       |          |                            |          |
       |          |    |<-- PSN Tunnel -->|    |          |
       | PW End   V    V                  V    V  PW End  |
       V Service  +----+                  +----+  Service V
 +-----+    |     | PE1|==================| PE2|     |    +-----+
 |     |----------|............PW1.............|----------|     |
 | CE1 |    |     |    |                  |    |     |    | CE2 |
 |     |----------|............PW2.............|----------|     |
 +-----+  ^ |     |    |==================|    |     | ^  +-----+
       ^  |       +----+                  +----+     | |  ^
       |  |   Provider Edge 1         Provider Edge 2  |  |
       |  |       (PE1)                    (PE2)       |  |
 Customer |                                            | Customer
 Edge 1   |                                            | Edge 2
          |                                            |
          |                                            |
  Attachment Circuit (AC)                    Attachment Circuit (AC)
 native frame relay service                 native frame relay service
 Figure 1.  PWE3 frame relay PVC interface reference configuration
 Two mapping modes can be defined between frame relay VCs and
 pseudowires: The first one is called "one-to-one" mapping, because
 there is a one-to-one correspondence between a frame relay VC and one
 pseudowire.  The second mapping is called "many-to-one" mapping or
 "port mode" because multiple frame relay VCs assigned to a port are
 mapped to one pseudowire.  The "port mode" encapsulation is identical
 to High-Level Data Link Control (HDLC) pseudowire encapsulation,
 which is described in [RFC4618].

Martini & Kawa Standards Track [Page 3] RFC 4619 Encapsulation for Transport of Frame Relay September 2006

2. 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 RFC 2119.
 Below are the definitions for the terms used throughout the document.
 PWE3 definitions can be found in [RFC3916, RFC3985].  This section
 defines terms specific to frame relay.
  1. Forward direction
   The forward direction is the direction taken by the frame being
   forwarded.
  1. Backward direction
   In frame relay, it is the direction opposite to the direction taken
   by a frame being forwarded (see also forward direction).

3. Co-authors

 The following are co-authors of this document:
 Nasser El-Aawar           Level 3 Communications, LLC
 Eric C. Rosen             Cisco Systems
 Daniel Tappan             Cisco Systems
 Thomas K. Johnson         Litchfield Communications
 Kireeti Kompella          Juniper Networks, Inc.
 Steve Vogelsang           Laurel Networks, Inc.
 Vinai Sirkay              Reliance Infocomm
 Ravi Bhat                 Nokia
 Nishit Vasavada           Nokia
 Giles Heron               Tellabs
 Dimitri Stratton Vlachos  Mazu Networks,Inc.
 Chris Liljenstolpe        Cable & Wireless
 Prayson Pate              Overture Networks, Inc

Martini & Kawa Standards Track [Page 4] RFC 4619 Encapsulation for Transport of Frame Relay September 2006

4. Acronyms and Abbreviations

    BECN    Backward Explicit Congestion Notification
    CE      Customer Edge
    C/R     Command/Response
    DE      Discard Eligibility
    DLCI    Data Link Connection Identifier
    FCS     Frame Check Sequence
    FECN    Forward Explicit Congestion Notification
    FR      Frame Relay
    LSP     Label Switched Path
    LSR     Label Switching Router
    MPLS    Multiprotocol Label Switching
    MTU     Maximum Transfer Unit
    NNI     Network-Network Interface
    PE      Provider Edge
    PSN     Packet Switched Network
    PW      Pseudowire
    PWE3    Pseudowire Emulation Edge to Edge
    POS     Packet over SONET/SDH
    PVC     Permanent Virtual Circuit
    QoS     Quality of Service
    SVC     Switched Virtual Circuit
    UNI     User-Network Interface
    VC      Virtual Circuit

5. Applicability Statement

 Frame relay over PW service is not intended to emulate the
 traditional frame relay service perfectly, but it can be used for
 applications that need frame relay transport service.
 The following are notable differences between traditional frame relay
 service and the protocol described in this document:
  1. Frame ordering can be preserved using the OPTIONAL sequence field

in the control word; however, implementations are not required to

   support this feature.
  1. The Quality of Service model for traditional frame relay can be

emulated; however, this is outside the scope of this document.

  1. A Frame relay port mode PW does not process any frame relay status

messages or alarms as described in [Q922] [Q933]

  1. The frame relay BECN and FECN bit are transparent to the MPLS

network and cannot reflect the status of the MPLS network.

Martini & Kawa Standards Track [Page 5] RFC 4619 Encapsulation for Transport of Frame Relay September 2006

  1. Support for frame relay SVC and Switched Permanent Virtual Circuit

(SPVC) is outside the scope of this document.

  1. Frame relay Local Management Interface (LMI) is terminated locally

in the PE connected to the frame relay attachment circuit.

  1. The support of PVC link integrity check is outside the scope of

this document.

6. General Encapsulation Method

 The general frame relay pseudowire packet format for carrying frame
 relay information (user's payload and frame relay control
 information) between two PEs is shown in Figure 2.
            +-------------------------------+
            |                               |
            |    MPLS Transport header      |
            |       (As required)           |
            +-------------------------------+
            |   Pseudowire (PW) Header      |
            +-------------------------------+
            |        Control Word           |
            +-------------------------------+
            |          FR Service           |
            |           Payload             |
            +-------------------------------+
  Figure 2.  General format of frame relay encapsulation over PSN
 The PW packet consists of the following fields: Control word and
 Payload, preceded by the MPLS Transport and pseudowire header.  The
 meaning of the different fields is as follows:
  1. i. MPLS Transport header is specific to the MPLS network. This

header is used to switch the PW packet through the MPLS core.

  1. ii. PW header contains an identifier for multiplexing PWs within

an MPLS tunnel.

  1. iii. Control Word contains protocol control information for

providing a frame relay service. Its structure is provided in

        the following sections.
  1. iv. The content of the frame relay service payload field depends

on the mapping mode. In general it contains the layer 2 frame

        relay frame.

Martini & Kawa Standards Track [Page 6] RFC 4619 Encapsulation for Transport of Frame Relay September 2006

7. Frame Relay over MPLS PSN for the One-to-One Mode

7.1. MPLS PSN Tunnel and PW

 MPLS label switched paths (LSPs) called "MPLS Tunnels" are used
 between PEs and are used within the MPLS core network to forward PW
 packets.  An MPLS tunnel corresponds to "PSN Tunnel" of Figure 1.
 Several PWs may be nested inside one MPLS tunnel.  Each PW carries
 the traffic of a single frame relay VC.  In this case, the PW header
 is an MPLS label called the PW label.

7.2. Packet Format over MPLS PSN

 For the one-to-one mapping mode for frame relay over an MPLS network,
 the PW packet format is as shown in Figure 3.
  +-------------------------------+
  |      MPLS Tunnel label(s)     | n*4 octets (four octets per label)
  +-------------------------------+
  |      PW label                 |  4 octets
  +-------------------------------+
  |       Control Word            |
  |      (See Figure 4)           | 4 octets
  +-------------------------------+
  |            Payload            |
  |      (Frame relay frame       |
  |       information field)      | n octets
  |                               |
  +-------------------------------+
        Figure 3.  Frame Relay over MPLS PSN Packet for the
                   One-to-One Mapping
 The meaning of the different fields is as follows:
  1. MPLS Tunnel label(s)
   The MPLS Tunnel label(s) corresponds to the MPLS transport header
   of Figure 2.  The label(s) is/are used by MPLS LSRs to forward a PW
   packet from one PE to the other.
  1. PW Label
   The PW label identifies one PW (i.e., one LSP) assigned to a frame
   relay VC in one direction.  It corresponds to the PW header of
   Figure 2.  Together the MPLS Tunnel label(s) and PW label form an
   MPLS label stack [RFC3032].

Martini & Kawa Standards Track [Page 7] RFC 4619 Encapsulation for Transport of Frame Relay September 2006

  1. Control Word
   The Control Word contains protocol control information.  Its
   structure is shown in Figure 4.
  1. Payload
   The payload field corresponds to X.36/X.76 frame relay frame
   information field with the following components removed: bit/byte
   stuffing, frame relay header, and FCS.  It is RECOMMENDED to
   support a frame size of at least 1600 bytes.  The maximum length of
   the payload field MUST be agreed upon by the two PEs.  This can be
   achieved by using the MTU interface parameter when the PW is
   established.  [RFC4447]

7.3. The Control Word

 The control word defined below is REQUIRED for frame relay one-to-one
 mode.  The control word carries certain frame relay specific
 information that is necessary to regenerate the frame relay frame on
 the egress PE.  Additionally, the control word also carries a
 sequence number that can be used to preserve sequentiality when
 carrying frame relay over an MPLS network.  Its structure is as
 follows:
  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |0 0 0 0|F|B|D|C|FRG|  Length   | Sequence Number               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Figure 4.  Control Word structure for the one-to-one mapping mode
 The meaning of the Control Word fields (Figure 4) is as follows (see
 also [X36 and X76] for frame relay bits):
  1. Bits 0 to 3
    In the above diagram, the first 4 bits MUST be set to 0 to
    indicate PW data.
  1. F (bit 4) FR FECN (Forward Explicit Congestion Notification) bit.
  1. B (bit 5) FR BECN (Backward Explicit Congestion Notification) bit.
  1. D (bit 6) FR DE bit (Discard Eligibility) bit.
  1. C (bit 7) FR frame C/R (Command/Response) bit.

Martini & Kawa Standards Track [Page 8] RFC 4619 Encapsulation for Transport of Frame Relay September 2006

  1. FRG (bits 8 and 9): These bits are defined by [RFC4623].
  1. Length (bits 10 to 15)
    If the PW traverses a network link that requires a minimum frame
    size (a notable example is Ethernet), padding is required to reach
    its minimum frame size.  If the frame's length (defined as the
    length of the layer 2 payload plus the length of the control word)
    is less than 64 octets, the length field MUST be set to the PW
    payload length.  Otherwise, the length field MUST be set to zero.
    The value of the length field, if non-zero, is used to remove the
    padding characters by the egress PE.
  1. Sequence number (Bit 16 to 31)
    Sequence numbers provide one possible mechanism to ensure the
    ordered delivery of PW packets.  The processing of the sequence
    number field is OPTIONAL.  The sequence number space is a 16-bit
    unsigned circular space.  The sequence number value 0 is used to
    indicate that the sequence number check algorithm is not used.

7.4. The Martini Legacy Mode Control Word

 For backward compatibility to existing implementations, the following
 version of the control word is defined as the "martini mode CW" for
 frame relay.
  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |0 0 0 0|B|F|D|C|FRG|  Length   | Sequence Number               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Figure 5.  Control Word structure for the frame relay martini mode
 Note that the "B" and "F" bits are reversed.
 This control word format is used for PW type "Frame Relay DLCI (
 Martini Mode )"

7.5. PW Packet Processing

7.5.1. Encapsulation of Frame Relay Frames

 The encapsulation process of a frame relay frame is initiated when a
 PE receives a frame relay frame from one of its frame relay UNI or
 NNI [FRF1] [FRF2] interfaces.  The PE generates the following fields

Martini & Kawa Standards Track [Page 9] RFC 4619 Encapsulation for Transport of Frame Relay September 2006

 of the control word from the corresponding fields of the frame relay
 frame as follows:
  1. Command/Response (C/R or C) bit: The C bit is copied unchanged in

the PW Control Word.

  1. The DE bit of the frame relay frame is copied into the D bit field.

However, if the D bit is not already set, it MAY be set as a result

   of ingress frame policing.  If it is not already set by the copy
   operation, setting of this bit by a PE is OPTIONAL.  The PE MUST
   NOT clear this bit (set it to 0 if it was received with the value
   of 1).
  1. The FECN bit of the frame relay frame is copied into the F bit

field. However, if the F bit is not already set, it MAY be set to

   reflect a congestion situation detected by the PE.  If it is not
   already set by the copy operation, setting of this bit by a PE is
   OPTIONAL.  The PE MUST NOT clear this bit (set it to 0 if it was
   received with the value of 1)
  1. The BECN bit of the frame relay frame is copied into the B bit

field. However, if the B bit is not already set, it MAY be set to

   reflect a congestion situation detected by the PE.  If it is not
   already set by the copy operation, setting of this bit by a PE is
   OPTIONAL.  The PE MUST NOT clear this bit (set it to 0 if it was
   received with the value of 1).
  1. If the PW packet length (defined as the length of the payload plus

the length of the control word) is less than 64 octets, the length

   field MUST be set to the packet's length.  Otherwise, the length
   field MUST be set to zero.
  1. The sequence number field is processed if the PW uses sequence

numbers. [RFC4385]

  1. The payload of the PW packet is the contents of ITU-T

Recommendations X.36/X.76 [X36] [X76] frame relay frame information

   field stripped from any bit or byte stuffing.

7.5.2. Setting the Sequence Number

 For a given PW and a pair of routers PE1 and PE2, if PE1 supports
 packet sequencing, then the procedures in [RFC4385], Section 4.1,
 MUST be followed.

Martini & Kawa Standards Track [Page 10] RFC 4619 Encapsulation for Transport of Frame Relay September 2006

7.6. Decapsulation of PW Packets

 When a PE receives a PW packet, it processes the different fields of
 the control word in order to decapsulate the frame relay frame for
 transmission to a CE on a frame relay UNI or NNI.  The PE performs
 the following actions (not necessarily in the order shown):
  1. It generates the following frame relay frame header fields from the

corresponding fields of the PW packet.

  1. The C/R bit MUST be copied in the frame relay header.
  1. The D bit MUST be copied into the frame relay header DE bit.
  1. The F bit MUST be copied into the frame relay header FECN bit. If

the F bit is set to zero, the FECN bit may be set to one, depending

   on the congestion state of the PE device in the forward direction.
   Changing the state of this bit by a PE is OPTIONAL.
  1. The B bit MUST be copied into the frame relay header BECN bit. If

the B bit is set to zero, the BECN bit may be set to one, depending

   on the congestion state of the PE device in the backward direction.
   Changing the state of this bit by a PE is OPTIONAL.
  1. It processes the length and sequence field, the details of which

are in the following sub-sections.

  1. It copies the frame relay information field from the contents of

the PW packet payload after removing any padding.

 Once the above fields of a FR frame have been processed, the standard
 HDLC operations are performed on the frame relay frame: the HDLC
 header is added, any bit or byte stuffing is added as required, and
 the FCS is also appended to the frame.  The FR frame is then queued
 for transmission on the selected frame relay UNI or NNI interface.

7.6.1. Processing the Sequence Number

 If a router PE2 supports received sequence number processing, then
 the procedures in [RFC4385], Section 4.2, MUST be used.

7.6.2. Processing of the Length Field by the Receiver

 Any padding octet, if present, in the payload field of a PW packet
 received MUST be removed before forwarding the data.
  1. If the Length field is set to zero, then there are no padding

octets following the payload field.

Martini & Kawa Standards Track [Page 11] RFC 4619 Encapsulation for Transport of Frame Relay September 2006

  1. Otherwise, if the payload is longer, then the length specified in

the control word padding characters are removed according to the

   length field.

7.7. MPLS Shim EXP Bit Values

 If it is desired to carry Quality of Service information, the Quality
 of Service information SHOULD be represented in the Experimental Use
 Bits (EXP) field of the PW MPLS label [RFC3032].  If more than one
 MPLS label is imposed by the ingress LSR, the EXP field of any labels
 higher in the stack SHOULD also carry the same value.

7.8. MPLS Shim S Bit Value

 The ingress LSR, PE1, MUST set the S bit of the PW label to a value
 of 1 to denote that the PW label is at the bottom of the stack.

7.9. Control Plane Details for Frame Relay Service

 The PE MUST provide frame relay PVC status signaling to the frame
 relay network.  If the PE detects a service-affecting condition for a
 particular DLCI, as defined in [Q933] Q.933, Annex A.5, sited in IA
 FRF1.1, the PE MUST communicate to the remote PE the status of the PW
 that corresponds to the frame relay DLCI status.  The Egress PE
 SHOULD generate the corresponding errors and alarms as defined in
 [Q922] [Q933] on the egress Frame relay PVC.
 There are two frame relay flags to control word bit mappings
 described below.  The legacy bit ordering scheme will be used for a
 PW of type 0x0001, "Frame Relay DLCI (Martini Mode)", and the new bit
 ordering scheme will be used for a PW of type 0x0019, "Frame Relay
 DLCI".  The IANA allocation registry of "Pseudowire Type" is defined
 in [RFC4446] along with initial allocated values.

7.9.1. Frame Relay Specific Interface Parameter Sub-TLV

 A separate document, [RFC4447], describes the PW control and
 maintenance protocol in detail, including generic interface parameter
 sub-TLVs.  The interface parameter information, when applicable, MUST
 be used to validate that the PEs and the ingress and egress ports at
 the edges of the circuit have the necessary capabilities to
 interoperate with each other.  The Interface parameter TLV is defined
 in [RFC4447], and the IANA registry with initial values for interface
 parameter sub-TLV types is defined in [RFC4446], but the frame relay
 specific interface parameter sub-TLV types are specified as follows:
  1. 0x08 Frame Relay Header Length Sub-TLV

Martini & Kawa Standards Track [Page 12] RFC 4619 Encapsulation for Transport of Frame Relay September 2006

   An optional 16-bit value indicating the length of the FR Header,
   expressed in octets.  This OPTIONAL interface parameter Sub-TLV can
   have value of 2, 3, or 4, the default being 2.  If this Sub-TLV is
   not present, the default value of 2 is assumed.

8. Frame Relay Port Mode

 The frame relay port mode PW shares the same encapsulation as the
 HDLC PW and is described in the respective document.  [RFC4618]

9. Congestion Control

 As explained in [RFC3985], the PSN carrying the PW may be subject to
 congestion, the characteristics of which depend on PSN type, network
 architecture, configuration, and loading.  During congestion, the PSN
 may exhibit packet loss that will impact the service carried by the
 frame relay PW.  In addition, since frame relay PWs carry a variety
 of services across the PSN, including but not restricted to TCP/IP,
 they may or may not behave in a TCP-friendly manner prescribed by
 [RFC2914].  In the presence of services that reduce transmission
 rate, frame relay PWs may thus consume more than their fair share and
 in that case SHOULD be halted.
 Whenever possible, frame relay PWs should be run over traffic-
 engineered PSNs providing bandwidth allocation and admission control
 mechanisms.  IntServ-enabled domains providing the Guaranteed Service
 (GS) or DiffServ-enabled domains using EF (expedited forwarding) are
 examples of traffic-engineered PSNs.  Such PSNs will minimize loss
 and delay while providing some degree of isolation of the frame relay
 PW's effects from neighboring streams.
 Note that when transporting frame relay, DiffServ-enabled domains may
 use AF (Assured Forwarding) and/or DF (Default Forwarding) instead of
 EF, in order to place less burden on the network and to gain
 additional statistical multiplexing advantage.  In particular, if the
 Committed Information Rate (CIR) of a frame relay VC is zero, then it
 is equivalent to a best-effort UDP over IP stream regarding
 congestion:  the network is free to drop frames as necessary.  In
 this case, the "DF" Per Hop Behavior (PHB) would be appropriate in a
 diff-serv-TE domain.  Alternatively, if the CIR of a frame relay VC
 is nonzero and the DE bit is zero in the FR header, then "AF31" would
 be appropriate to be used, and if the CIR of a frame relay VC is
 nonzero but the DE bit is on, then "AF32" would be appropriate
 [RFC3270].
 The PEs SHOULD monitor for congestion (by using explicit congestion
 notification, [VCCV], or by measuring packet loss) in order to ensure
 that the service using the frame relay PW may be maintained.  When a

Martini & Kawa Standards Track [Page 13] RFC 4619 Encapsulation for Transport of Frame Relay September 2006

 PE detects significant congestion while receiving the PW PDUs, the
 BECN bits of the frame relay frame transmitted on the same PW SHOULD
 be set to notify the remote PE and the remote frame relay switch of
 the congestion situation.  In addition, the FECN bits SHOULD be set
 in the FR frames sent out the attachment circuit, to give the FR DTE
 a chance to adjust its transport layer advertised window, if
 possible.
 If the PW has been set up using the protocol defined in [RFC4447],
 then procedures specified in [RFC4447] for status notification can be
 used to disable packet transmission on the ingress PE from the egress
 PE.  The PW may be restarted by manual intervention, or by automatic
 means after an appropriate waiting time.

10. Security Considerations

 PWE3 provides no means of protecting the contents or delivery of the
 PW packets on behalf of the native service.  PWE3 may, however,
 leverage security mechanisms provided by the MPLS Tunnel Layer.  A
 more detailed discussion of PW security is given in [RFC3985,
 RFC4447, RFC3916].

11. Normative References

 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G.
           Heron, "Pseudowire Setup and Maintenance Using the Label
           Distribution Protocol (LDP)", RFC 4447, April 2006.
 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson,
           "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
           Use over an MPLS PSN", RFC 4385, February 2006.
 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
           Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
           Encoding", RFC 3032, January 2001.
 [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge
           Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
 [RFC4618] Martini, L., Rosen, E., Heron, G., and A. Malis,
           "Encapsulation Methods for Transport of Point to Point
           Protocol/High-Level Data Link Control (PPP/HDLC) over
           Multiprotocol Label Switching (MPLS) Networks", RFC 4618,
           September 2006.
 [RFC4623] Malis, A. and M. Townsley, "Pseudowire Emulation Edge-to-
           Edge (PWE3) Fragmentation and Reassembly", RFC 4623, August
           2006.

Martini & Kawa Standards Track [Page 14] RFC 4619 Encapsulation for Transport of Frame Relay September 2006

12. Informative References

 [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-Edge
           (PWE3) Architecture", RFC 3985, March 2005.
 [VCCV]    Nadeau, T., et al., "Pseudo Wire Virtual Circuit Connection
           Verification (VCCV)", Work in Progress, October 2005.
 [ATM]     Martini, L., et al., "Encapsulation Methods for Transport
           of ATM Over MPLS Networks", Work in Progress, April 2005.
 [RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron,
           "Encapsulation Methods for Transport of Ethernet over MPLS
           Networks", RFC 4448, April 2006.
 [FRF1]    FRF.1.2, Frame relay PVC UNI Implementation Agreement,
           Frame Relay Forum, April 2000.
 [FRF2]    FRF.2.2, Frame relay PVC UNI Implementation Agreement,
           Frame Relay Forum, April 2002
 [RFC3916] Xiao, X., McPherson, D., and P. Pate, "Requirements for
           Pseudo-Wire Emulation Edge-to-Edge (PWE3)", RFC 3916,
           September 2004.
 [X36]     ITU-T Recommendation X.36, Interface between a DTE and DCE
           for public data networks providing frame relay, Geneva,
           2000.
 [X76]     ITU-T Recommendation X.76, Network-to-network interface
           between public data networks providing frame relay
           services, Geneva,2000
 [Q922]    ITU-T Recommendation Q.922 Specification for Frame Mode
           Basic call control, ITU Geneva 1995
 [Q933]    ITU-T Recommendation Q.933 Specification for Frame Mode
           Basic call control, ITU Geneva 2003
 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC
           2914, September 2000.
 [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen,
           P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-
           Protocol Label Switching (MPLS) Support of Differentiated
           Services", RFC 3270, May 2002.

Martini & Kawa Standards Track [Page 15] RFC 4619 Encapsulation for Transport of Frame Relay September 2006

Contributing Author Information

 Kireeti Kompella
 Juniper Networks
 1194 N. Mathilda Ave
 Sunnyvale, CA 94089
 EMail: kireeti@juniper.net
 Giles Heron
 Tellabs
 Abbey Place
 24-28 Easton Street
 High Wycombe
 Bucks
 HP11 1NT
 UK
 EMail: giles.heron@tellabs.com
 Rao Cherukuri
 Juniper Networks
 1194 N. Mathilda Ave
 Sunnyvale, CA 94089
 Dimitri Stratton Vlachos
 Mazu Networks, Inc.
 125 Cambridgepark Drive
 Cambridge, MA 02140
 EMail: d@mazunetworks.com
 Chris Liljenstolpe
 Alcatel
 11600 Sallie Mae Dr.
 9th Floor
 Reston, VA 20193
 EMail: chris.liljenstolpe@alcatel.com

Martini & Kawa Standards Track [Page 16] RFC 4619 Encapsulation for Transport of Frame Relay September 2006

 Nasser El-Aawar
 Level 3 Communications, LLC.
 1025 Eldorado Blvd.
 Broomfield, CO, 80021
 EMail: nna@level3.net
 Eric C. Rosen
 Cisco Systems, Inc.
 1414 Massachusetts Avenue
 Boxborough, MA 01719
 EMail: erosen@cisco.com
 Dan Tappan
 Cisco Systems, Inc.
 1414 Massachusetts Avenue
 Boxborough, MA 01719
 EMail: tappan@cisco.com
 Prayson Pate
 Overture Networks, Inc.
 507 Airport Boulevard
 Morrisville, NC, USA 27560
 EMail: prayson.pate@overturenetworks.com
 David Sinicrope
 Ericsson IPI
 EMail: david.sinicrope@ericsson.com
 Ravi Bhat
 Nokia
 EMail: ravi.bhat@nokia.com
 Nishit Vasavada
 Nokia
 EMail: nishit.vasavada@nokia.com

Martini & Kawa Standards Track [Page 17] RFC 4619 Encapsulation for Transport of Frame Relay September 2006

 Steve Vogelsang
 ECI Telecom
 Omega Corporate Center
 1300 Omega Drive
 Pittsburgh, PA 15205
 EMail: stephen.vogelsang@ecitele.com
 Vinai Sirkay
 Redback Networks
 300 Holger Way,
 San Jose, CA 95134
 EMail: sirkay@technologist.com

Authors' Addresses

 Luca Martini
 Cisco Systems, Inc.
 9155 East Nichols Avenue, Suite 400
 Englewood, CO, 80112
 EMail: lmartini@cisco.com
 Claude Kawa
 OZ Communications
 Windsor Station
 1100, de la Gauchetie`re St West
 Montreal QC Canada
 H3B 2S2
 EMail: claude.kawa@oz.com
 Andrew G. Malis
 Tellabs
 1415 West Diehl Road
 Naperville, IL  60563
 EMail: Andy.Malis@tellabs.com

Martini & Kawa Standards Track [Page 18] RFC 4619 Encapsulation for Transport of Frame Relay September 2006

Full 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.
 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.

Intellectual Property

 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.

Acknowledgement

 Funding for the RFC Editor function is provided by the IETF
 Administrative Support Activity (IASA).

Martini & Kawa Standards Track [Page 19]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4619.txt · Last modified: 2006/09/28 22:20 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki