doc: Add RFC documents

1 files changed, 899 insertions, 0 deletions

diff --git a/doc/rfc/rfc4618.txt b/doc/rfc/rfc4618.txt
new file mode 100644
index 0000000..9c56e0c
--- /dev/null
+++ b/doc/rfc/rfc4618.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Network Working Group                                         L. Martini
+Request for Comments: 4618                                      E. Rosen
+Category: Standards Track                            Cisco Systems, Inc.
+                                                                G. Heron
+                                                                A. Malis
+                                                                 Tellabs
+                                                          September 2006
+
+
+                Encapsulation Methods for Transport of
+       PPP/High-Level Data Link Control (HDLC) over 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 pseudowire (PW) can be used to carry Point to Point Protocol (PPP)
+   or High-Level Data Link Control (HDLC) Protocol Data Units over a
+   Multiprotocol Label Switching (MPLS) network without terminating the
+   PPP/HDLC protocol.  This enables service providers to offer
+   "emulated" HDLC, or PPP link services over existing MPLS networks.
+   This document specifies the encapsulation of PPP/HDLC Packet Data
+   Units (PDUs) within a pseudowire.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Martini, et al.             Standards Track                     [Page 1]
+
+RFC 4618            Transport of PPP/HDLC over MPLS       September 2006
+
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. Specification of Requirements ...................................2
+   3. Applicability Statement .........................................5
+   4. General Encapsulation Method ....................................6
+      4.1. The Control Word ...........................................6
+      4.2. MTU Requirements ...........................................8
+   5. Protocol-Specific Details .......................................9
+      5.1. HDLC .......................................................9
+      5.2. Frame Relay Port Mode ......................................9
+      5.3. PPP .......................................................10
+   6. Using an MPLS Label as the Demultiplexer Field .................11
+      6.1. MPLS Shim EXP Bit Values ..................................11
+      6.2. MPLS Shim S Bit Value .....................................11
+   7. Congestion Control .............................................12
+   8. IANA Considerations ............................................12
+   9. Security Considerations ........................................12
+   10. Normative References ..........................................13
+   11. Informative References ........................................13
+
+1.  Introduction
+
+   A PPP/HDLC pseudowire (PW) allows PPP/HDLC Protocol Data Units (PDUs)
+   to be carried over an MPLS network.  In addressing the issues
+   associated with carrying a PPP/HDLC PDU over an MPLS network, this
+   document assumes that a PW has been set up by some means outside the
+   scope of this document.  This may be via manual configuration, or
+   using a signaling protocol such as that defined in [RFC4447].
+
+   The following figure describes the reference models that are derived
+   from [RFC3985] to support the HDLC/PPP PW emulated services.  The
+   reader is also assumed to be familiar with the content of the
+   [RFC3985] document.
+
+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 [RFC2119].
+
+
+
+
+
+
+
+
+
+
+
+Martini, et al.             Standards Track                     [Page 2]
+
+RFC 4618            Transport of PPP/HDLC over MPLS       September 2006
+
+
+          |<-------------- Emulated Service ---------------->|
+          |                                                  |
+          |          |<------- Pseudowire ------->|          |
+          |          |                            |          |
+          |          |    |<-- PSN Tunnel -->|    |          |
+          |          V    V                  V    V          |
+          V   AC     +----+                  +----+    AC    V
+    +-----+    |     | PE1|==================| PE2|     |    +-----+
+    |     |----------|............PW1.............|----------|     |
+    | CE1 |    |     |    |                  |    |     |    | CE2 |
+    |     |----------|............PW2.............|----------|     |
+    +-----+  ^ |     |    |==================|    |     | ^  +-----+
+          ^  |       +----+                  +----+     | |  ^
+          |  |   Provider Edge 1         Provider Edge 2  |  |
+          |  |                                            |  |
+    Customer |                                            | Customer
+    Edge 1   |                                            | Edge 2
+             |                                            |
+             |                                            |
+       native HDLC/PPP service                   native HDLC/PPP service
+
+       Figure 1.  PWE3 HDLC/PPP interface reference configuration
+
+   This document specifies the emulated PW encapsulation for PPP and
+   HDLC; however, quality of service related issues are not discussed in
+   this document.  For the purpose of the discussion in this document,
+   PE1 will be defined as the ingress router and PE2 as the egress
+   router.  A layer 2 PDU will be received at PE1, encapsulated at PE1,
+   transported across the network, decapsulated at PE2, and transmitted
+   out on an attachment circuit at PE2.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Martini, et al.             Standards Track                     [Page 3]
+
+RFC 4618            Transport of PPP/HDLC over MPLS       September 2006
+
+
+   The following reference model describes the termination point of each
+   end of the PW within the PE:
+
+                +-----------------------------------+
+                |                PE                 |
+        +---+   +-+  +-----+  +------+  +------+  +-+
+        |   |   |P|  |     |  |PW ter|  | PSN  |  |P|
+        |   |<==|h|<=| NSP |<=|minati|<=|Tunnel|<=|h|<== From PSN
+        |   |   |y|  |     |  |on    |  |      |  |y|
+        | C |   +-+  +-----+  +------+  +------+  +-+
+        | E |   |                                   |
+        |   |   +-+  +-----+  +------+  +------+  +-+
+        |   |   |P|  |     |  |PW ter|  | PSN  |  |P|
+        |   |==>|h|=>| NSP |=>|minati|=>|Tunnel|=>|h|==> To PSN
+        |   |   |y|  |     |  |on    |  |      |  |y|
+        +---+   +-+  +-----+  +------+  +------+  +-+
+                |                                   |
+                +-----------------------------------+
+                        ^        ^          ^
+                        |        |          |
+                        A        B          C
+
+                       Figure 2.  PW reference diagram
+
+   The PW terminates at a logical port within the PE, defined at point B
+   in the above diagram.  This port provides an HDLC Native Service
+   Processing function that will deliver each PPP/HDLC packet that is
+   received at point A, unaltered, to the point A in the corresponding
+   PE at the other end of the PW.
+
+   The Native Service Processing (NSP) function includes packet
+   processing that is required for the PPP/HDLC packets that are
+   forwarded to the PW termination point.  Such functions may include
+   bit stuffing, PW-PW bridging, L2 encapsulation, shaping, and
+   policing.  These functions are specific to the native packet
+   technology and may not be required for the PW emulation service.
+
+   The points to the left of B, including the physical layer between the
+   CE and PE, and any adaptation (NSP) functions between it and the PW
+   terminations, are outside of the scope of PWE3 and are not defined
+   here.
+
+   "PW Termination", between A and B, represents the operations for
+   setting up and maintaining the PW, and for encapsulating and
+   decapsulating the PPP/HDLC packets as necessary to transmit them
+   across the MPLS network.
+
+
+
+
+
+Martini, et al.             Standards Track                     [Page 4]
+
+RFC 4618            Transport of PPP/HDLC over MPLS       September 2006
+
+
+3.  Applicability Statement
+
+   PPP/HDLC transport over PW service is not intended to emulate the
+   traditional PPP or HDLC service perfectly, but it can be used for
+   some applications that require PPP or HDLC transport service.
+
+   The applicability statements in [RFC4619] also apply to the Frame
+   Relay port mode PW described in this document.
+
+   The following are notable differences between traditional PPP/HDLC
+   service, and the protocol described in this document:
+
+   - Packet ordering can be preserved using the OPTIONAL sequence field
+     in the control word; however, implementations are not required to
+     support this feature.
+
+   - The Quality of Service model for traditional PPP/HDLC links can be
+     emulated, however this is outside the scope of this document.
+
+   - A Frame Relay Port mode PW, or HDLC PW, does not process any frame
+     relay status messages or alarms as described in [Q922] [Q933].
+
+   - The HDLC Flags are processed locally in the PE connected to the
+     attachment circuit.
+
+   The HDLC mode is suitable for port-to-port transport of Frame Relay
+   User Network Interface (UNI) or Network Node Interface (NNI) traffic.
+   Since all packets are passed in a largely transparent manner over the
+   HDLC PW, any protocol that has HDLC-like framing may use the HDLC PW
+   mode, including PPP, Frame-Relay, and X.25.  Exceptions include cases
+   where direct access to the HDLC interface is required, or modes that
+   operate on the flags, Frame Check Sequence (FCS), or bit/byte
+   unstuffing that is performed before sending the HDLC PDU over the PW.
+   An example of this is PPP Asynchronous-Control-Character-Map (ACCM)
+   negotiation.
+
+   For PPP, since media-specific framing is not carried, the following
+   options will not operate correctly if the PPP peers attempt to
+   negotiate them:
+
+   - Frame Check Sequence (FCS) Alternatives
+
+   - Address-and-Control-Field-Compression (ACFC)
+
+   - Asynchronous-Control-Character-Map (ACCM)
+
+   Note, also, that PW LSP Interface MTU negotiation, as specified in
+   [RFC4447], is not affected by PPP Maximum Receive Unit (MRU)
+
+
+
+Martini, et al.             Standards Track                     [Page 5]
+
+RFC 4618            Transport of PPP/HDLC over MPLS       September 2006
+
+
+   advertisement.  Thus, if a PPP peer sends a PDU with a length in
+   excess of that negotiated for the PW tunnel, that PDU will be
+   discarded by the ingress router.
+
+4.  General Encapsulation Method
+
+   This section describes the general encapsulation format for PPP and
+   HDLC packets over MPLS pseudowires.
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |               PSN Transport Header (As Required)              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                     Pseudowire Header                         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                     Control Word                              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                     PPP/HDLC Service Payload                  |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+     Figure 3.  General format for PPP/HDLC encapsulation over PSNs
+
+   The PSN Transport Header depends on the particular tunneling
+   technology in use.  This header is used to transport the encapsulated
+   PPP/HDLC information through the packet-switched core.
+
+   The Pseudowire Header identifies a particular PPP/HDLC service on a
+   tunnel.  In case the of MPLS, the Pseudowire Header is the MPLS label
+   at the bottom of the MPLS label stack.
+
+   The Control Word is inserted before the PPP/HDLC service payload.  It
+   may contain a length and sequence number.
+
+4.1.  The Control Word
+
+   There are four requirements that may need to be satisfied when
+   transporting layer 2 protocols over an MPLS PSN:
+
+   i.    Sequentiality may need to be preserved.
+
+   ii.   Small packets may need to be padded in order to be transmitted
+         on a medium where the minimum transport unit is larger than the
+         actual packet size.
+
+   iii.  Control bits carried in the header of the layer 2 packet may
+         need to be transported.
+
+
+
+
+Martini, et al.             Standards Track                     [Page 6]
+
+RFC 4618            Transport of PPP/HDLC over MPLS       September 2006
+
+
+   iv.   Creating an in-band associated channel for operation and
+         maintenance communications.
+
+   The Control Word defined in this section is based on the Generic PW
+   MPLS Control Word, as defined in [RFC4385].  It provides the ability
+   to sequence individual packets on the PW and avoidance of equal-cost
+   multiple-path load-balancing (ECMP) [RFC2992] and enables Operations
+   and Management (OAM) mechanisms, including [VCCV].
+
+   [RFC4385] states, "If a PW is sensitive to packet mis-ordering and is
+   being carried over an MPLS PSN that uses the contents of the MPLS
+   payload to select the ECMP path, it MUST employ a mechanism which
+   prevents packet mis-ordering."  This is necessary because ECMP
+   implementations may examine the first nibble after the MPLS label
+   stack to determine whether the content of the labeled packet is IP.
+   Thus, if the PPP protocol number of a PPP packet carried over the PW
+   without a control word present begins with 0x4 or 0x6, it could be
+   mistaken for an IPv4 or IPv6 packet.  This could, depending on the
+   configuration and topology of the MPLS network, lead to a situation
+   where all packets for a given PW do not follow the same path.  This
+   may increase out-of-order packets on a given PW or cause OAM packets
+   to follow a different path from that of actual traffic.
+
+   The features that the control word provides may not be needed for a
+   given PPP/HDLC PW.  For example, ECMP may not be present or active on
+   a given MPLS network, and strict packet sequencing may not be
+   required.  If this is the case, the control word provides little
+   value and is therefore optional.  Early PPP/HDLC PW implementations
+   have been deployed that do not include a control word or the ability
+   to process one if present.  To aid in backwards compatibility, future
+   implementations MUST be able to send and receive packets without the
+   control word.
+
+   In all cases, the egress PE MUST be aware of whether the ingress PE
+   will send a control word over a specific PW.  This may be achieved by
+   configuration of the PEs, or by signaling, as defined in [RFC4447].
+
+   The control word is defined 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|0 0 0 0|FRG|   Length  |     Sequence Number           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                   Figure 4.  MPLS PWE3 control word
+
+
+
+
+
+Martini, et al.             Standards Track                     [Page 7]
+
+RFC 4618            Transport of PPP/HDLC over MPLS       September 2006
+
+
+   In the above diagram, the first 4 bits are set to 0 in indicate a CW
+   [RFC4385].
+
+   The next 4 bits provide space for carrying protocol-specific flags.
+   These are not used for HDLC/PPP, and they MUST be set to 0 for
+   transmitting and MUST be ignored upon receipt.
+
+   The next 2 bits are defined in [RFC4623].
+
+   The next 6 bits provide a length field, which is used as follows: If
+   the packet's length (defined as the length of the layer 2 payload
+   plus the length of the control word) is less than 64 bytes, the
+   length field MUST be set to the packet's length.  Otherwise, the
+   length field MUST be set to zero.  The value of the length field, if
+   not zero, is used to remove any padding that may have been added by
+   the MPLS network.  If the control word is used and padding was added
+   to the packet in transit on the MPLS network, then when the packet
+   reaches the egress PE the padding MUST be removed before forwarding
+   the packet.
+
+   The next 16 bits provide a sequence number that can be used to
+   guarantee ordered packet delivery.  The processing of the sequence
+   number field is OPTIONAL.[RFC4385]
+
+   The sequence number space is a 16-bit, unsigned circular space.  The
+   sequence number value 0 is used to indicate an unsequenced
+   packet.[RFC4385]
+
+   The procedures described in Section 4 of [RFC4385] MUST be followed
+   to process the sequence number field.
+
+4.2.  MTU Requirements
+
+   The network MUST be configured with an MTU that is sufficient to
+   transport the largest encapsulation packets.  When MPLS is used as
+   the tunneling protocol, for example, this is likely to be 12 or more
+   bytes greater than the largest packet size.  The methodology
+   described in [RFC4623] MAY be used to fragment encapsulated packets
+   that exceed the PSN MTU.  However, if [RFC4623] is not used, then if
+   the ingress router determines that an encapsulated layer 2 PDU
+   exceeds the MTU of the PSN tunnel through which it must be sent, the
+   PDU MUST be dropped.
+
+   If a packet is received on the attachment circuit that exceeds the
+   interface MTU subTLV value [RFC4447], it MUST be dropped.  It is also
+   RECOMMENDED that PPP devices be configured to not negotiate PPP MRUs
+   larger than that of the AC MTU.
+
+
+
+
+Martini, et al.             Standards Track                     [Page 8]
+
+RFC 4618            Transport of PPP/HDLC over MPLS       September 2006
+
+
+5.  Protocol-Specific Details
+
+5.1.  HDLC
+
+   HDLC mode provides port-to-port transport of HDLC-encapsulated
+   traffic.  The HDLC PDU is transported in its entirety, including the
+   HDLC address and control fields, but excluding HDLC flags and the
+   FCS.  Bit/Byte stuffing is undone.  If the OPTIONAL control word is
+   used, then the flag bits in the control word are not used and MUST be
+   set to 0 for transmitting and MUST be ignored upon receipt.
+
+   When the PE detects a status change in the attachment circuit status,
+   such as an attachment circuit physical link failure, or if the AC is
+   administratively disabled, the PE MUST send the appropriate PW status
+   notification message that corresponds to the HDLC AC status.  In a
+   similar manner, the local PW status MUST also be reflected in a
+   respective PW status notification message, as described in [RFC4447].
+
+   The PW of type 0x0006 "HDLC" will be used to transport HDLC packets.
+   The IANA allocation registry of "Pseudowire Type" is defined in the
+   IANA allocation document for PWs [RFC4446] along with initial
+   allocated values.
+
+5.2.  Frame Relay Port Mode
+
+   Figure 5 illustrates the concept of frame relay port mode or many-
+   to-one mapping, which is an OPTIONAL capability.
+
+   Figure 5a shows two frame relay devices physically connected with a
+   frame relay UNI or NNI.  Between their two ports, P1 and P2, n frame
+   relay Virtual Circuits (VCs) are configured.
+
+   Figure 5b shows the replacement of the physical frame relay interface
+   with a pair of PEs and a PW between them.  The interface between a
+   Frame Relay (FR) device and a PE is either an FR UNI or an NNI.  All
+   FR VCs carried over the interface are mapped into one HDLC PW.  The
+   standard frame relay Link Management Interface (LMI) procedures
+   happen directly between the CEs.  Thus with port mode, we have many-
+   to-one mapping between FR VCs and a PW.
+
+
+
+
+
+
+
+
+
+
+
+
+Martini, et al.             Standards Track                     [Page 9]
+
+RFC 4618            Transport of PPP/HDLC over MPLS       September 2006
+
+
+              +------+                          +-------+
+              | FR   |                          |   FR  |
+              |device|         FR UNI/NNI       | device|
+              |    [P1]------------------------[P2]     |
+              |      |      carrying n FR VCs   |       |
+              +------+                          +-------+
+
+                 [Pn]: A port
+
+                  Figure 5a.  FR interface between two FR devices
+
+
+                    |<---------------------------->|
+                    |                              |
+                     +----+                  +----+
+   +------+          |    |     One PW       |    |         +------+
+   |      |          |    |==================|    |         |      |
+   |  FR  |    FR    | PE1| carrying n FR VCs| PE2|    FR   |  FR  |
+   |device|----------|    |                  |    |---------|device|
+   | CE1  | UNI/NNI  |    |                  |    | UNI/NNI | CE2  |
+   +------+          +----+                  +----+         +------+
+          |                                                 |
+          |<----------------------------------------------->|
+                                  n FR VCs
+
+           Figure 5b.  Pseudowires replacing the FR interface
+
+   FR VCs are not visible individually to a PE; there is no
+   configuration of individual FR VC in a PE.  A PE processes the set of
+   FR VCs assigned to a port as an aggregate.
+
+   FR port mode provides transport between two PEs of a complete FR
+   frame using the same encapsulation as described above for HDLC mode.
+
+   Although frame relay port mode shares the same encapsulation as HDLC
+   mode, a different PW type is allocated in [RFC4446]: 0x000F Frame-
+   Relay Port mode.
+
+   All other aspects of this PW type are identical to the HDLC PW
+   encapsulation described above.
+
+5.3.  PPP
+
+   PPP mode provides point-to-point transport of PPP-encapsulated
+   traffic, as specified in [RFC1661].  The PPP PDU is transported in
+   its entirety, including the protocol field (whether compressed using
+   Protocol Field Compression or not), but excluding any media-specific
+   framing information, such as HDLC address and control fields or FCS.
+
+
+
+Martini, et al.             Standards Track                    [Page 10]
+
+RFC 4618            Transport of PPP/HDLC over MPLS       September 2006
+
+
+   If the OPTIONAL control word is used, then the flag bits in the
+   control word are not used and MUST be set to 0 for transmitting and
+   MUST be ignored upon receipt.
+
+   When the PE detects a status change in the attachment circuit (AC)
+   status, such as an attachment circuit physical link failure, or if
+   the AC is administratively disabled, the PE MUST send the appropriate
+   PW status notification message that corresponds to the PPP AC status.
+   Note that PPP negotiation status is transparent to the PW and MUST
+   NOT be communicated to the remote MPLS PE.  In a similar manner, the
+   local PW status MUST also be reflected in a respective PW status
+   notification message, as described in [RFC4447].
+
+   A PW of type 0x0007 "PPP" will be used to transport PPP packets.
+
+   The IANA allocation registry of "Pseudowire Type" is defined in the
+   IANA allocation document for PWs [RFC4446] along with initial
+   allocated values.
+
+6.  Using an MPLS Label as the Demultiplexer Field
+
+   To use an MPLS label as the demultiplexer field, a 32-bit label stack
+   entry [RFC3032] is simply prepended to the emulated PW encapsulation
+   and thus appears as the bottom label of an MPLS label stack.  This
+   label may be called the "PW label".  The particular emulated PW
+   identified by a particular label value must be agreed by the ingress
+   and egress LSRs, either by signaling (e.g., via the methods of
+   [RFC4447]) or by configuration.  Other fields of the label stack
+   entry are set as described below.
+
+6.1.  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 EXP field of the
+   PW label.  If more than one MPLS label is imposed by the ingress LSR,
+   the EXP field of any labels higher in the stack MUST also carry the
+   same value.
+
+6.2.  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.
+
+
+
+
+
+
+
+
+
+Martini, et al.             Standards Track                    [Page 11]
+
+RFC 4618            Transport of PPP/HDLC over MPLS       September 2006
+
+
+7.  Congestion Control
+
+   As explained in [RFC3985], the PSN carrying the PW may be subject to
+   congestion, the characteristics of which are dependent upon PSN type,
+   network architecture, configuration, and loading.  During congestion,
+   the PSN may exhibit packet loss that will impact the service carried
+   by the PPP/HLDC PW.  In addition, since PPP/HDLC PWs carry an
+   unspecified type of services across the PSN, they cannot behave in a
+   TCP-friendly manner prescribed by [RFC2914].  In the presence of
+   services that reduce transmission rate, PPP/HDLC PWs will thus
+   consume more than their fair share and SHOULD be halted.
+
+   Whenever possible, PPP/HDLC 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 PPP/HDLC PW's effects
+   from neighboring streams.
+
+   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 PPP/HDLC PW may be maintained.  When
+   significant congestion is detected, the PPP/HDLC PW SHOULD be
+   administratively disabled.  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.
+
+8.  IANA Considerations
+
+   This document has no new IANA Actions.  All necessary IANA actions
+   have already been included in [RFC4446].
+
+9.  Security Considerations
+
+   The PPP and HDLC pseudowire type is subject to all the general
+   security considerations discussed in [RFC3985][RFC4447].  This
+   document specifies only encapsulations, and not the protocols that
+   may be used to carry the encapsulated packets across the MPLS
+   network.  Each such protocol may have its own set of security issues,
+   but those issues are not affected by the encapsulations specified
+   herein.
+
+
+
+
+
+
+Martini, et al.             Standards Track                    [Page 12]
+
+RFC 4618            Transport of PPP/HDLC over MPLS       September 2006
+
+
+10.  Normative References
+
+   [RFC1661]    Simpson, W., "The Point-to-Point Protocol (PPP)", STD
+                51, RFC 1661, July 1994.
+
+   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
+                Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3032]    Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
+                Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
+                Encoding", RFC 3032, January 2001.
+
+   [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.
+
+   [RFC4446]    Martini, L., "IANA Allocations for Pseudowire Edge to
+                Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
+
+   [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.
+
+   [RFC4619]    Martini, L., Ed., Kawa, C., Ed., and A. Malis, Ed.,
+                "Encapsulation Methods for Transport of Frame Relay over
+                Multiprotocol Label Switching (MPLS) Networks", RFC
+                4619, September 2006.
+
+   [RFC4623]    Malis, A. and M. Townsley, "Pseudowire Emulation Edge-
+                to-Edge (PWE3) Fragmentation and Reassembly", RFC 4623,
+                August 2006.
+
+11.  Informative References
+
+   [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.
+
+   [RFC2992]    Hopps, C., "Analysis of an Equal-Cost Multi-Path
+                Algorithm", RFC 2992, November 2000.
+
+   [RFC3985]    Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation
+                Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005.
+
+
+
+Martini, et al.             Standards Track                    [Page 13]
+
+RFC 4618            Transport of PPP/HDLC over MPLS       September 2006
+
+
+   [VCCV]       Nadeau, T., et al., "Pseudo Wire Virtual Circuit
+                Connection Verification (VCCV)", Work in Progress,
+                October 2005.
+
+Contributing Author Information
+
+   Yeongil Seo
+   463-1 KT Technology Lab
+   Jeonmin-dong Yusung-gu
+   Daegeon, Korea
+
+   EMail: syi1@kt.co.kr
+
+
+   Toby Smith
+   Laurel Networks, Inc.
+   Omega Corporate Center
+   1300 Omega Drive
+   Pittsburgh, PA 15205
+
+   EMail: tob@laurelnetworks.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Martini, et al.             Standards Track                    [Page 14]
+
+RFC 4618            Transport of PPP/HDLC over MPLS       September 2006
+
+
+Authors' Addresses
+
+   Luca Martini
+   Cisco Systems, Inc.
+   9155 East Nichols Avenue, Suite 400
+   Englewood, CO, 80112
+
+   EMail: lmartini@cisco.com
+
+
+   Giles Heron
+   Tellabs
+   Abbey Place
+   24-28 Easton Street
+   High Wycombe
+   Bucks
+   HP11 1NT
+   UK
+
+   EMail: giles.heron@tellabs.com
+
+
+   Eric C. Rosen
+   Cisco Systems, Inc.
+   1414 Massachusetts Avenue
+   Boxborough, MA 01719
+
+   EMail: erosen@cisco.com
+
+
+   Andrew G. Malis
+   Tellabs
+   1415 West Diehl Road
+   Naperville, IL  60563
+
+   EMail: Andy.Malis@tellabs.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Martini, et al.             Standards Track                    [Page 15]
+
+RFC 4618            Transport of PPP/HDLC over MPLS       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, et al.             Standards Track                    [Page 16]
+