Skip to main content

Secure Session Layer Services KMP via HIP
draft-moskowitz-ssls-hip-02

Revision differences

Document history

Date Rev. By Action
2017-12-29
02 (System) Document has expired
2017-06-27
02 Robert Moskowitz New version available: draft-moskowitz-ssls-hip-02.txt
2017-06-27
02 (System) New version approved
2017-06-27
02 (System) Request for posting confirmation emailed to previous authors: Pierpaolo Giacomin , Susan Hares , Liang Xia , Robert Moskowitz , Igor Faynberg
2017-06-27
02 Robert Moskowitz Uploaded new revision
2017-04-30
01 (System) Document has expired
2016-10-27
01 Robert Moskowitz
New version available: draft-moskowitz-ssls-hip-01.txtMartini, et al.                                      …
New version available: draft-moskowitz-ssls-hip-01.txtMartini, et al.                                                [Page 2]
Internet Draft      draft-ietf-pwe3-atm-encap-11.txt            May 2006

  19      Intellectual Property Statement  ........................  34
  20      Normative References  ...................................  35
  21      Informative References  .................................  35
  22      Significant Contributors  ...............................  36
  23      Author Information  .....................................  39

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

2. Introduction

  Packet Switched Networks (PSNs) have the potential to reduce the
  complexity of a service providers infrastructure by allowing
  virtually any existing digital service to be supported over a single
  networking infrastructure. The benefit of this model to a service
  provider is threefold:
        -i. Leveraging of the existing systems and services to provide
            increased capacity from a packet switched core.
      -ii. Preserving existing network operational processes and
            procedures used to maintain the legacy services.
      -iii. Using the common packet switched network infrastructure to
            support both the core capacity requirements of existing
            services and the requirements of new services supported
            natively over the packet switched network.

  This document describes a method to carry ATM services over MPLS. It
  lists ATM specific requirements and provides encapsulation formats
  and semantics for connecting ATM edge networks through a packet
  switched network using MPLS.

  Figure 1, below displays the ATM services reference model. This model
  is adapted from [RFC3985].

Martini, et al.                                                [Page 3]
Internet Draft      draft-ietf-pwe3-atm-encap-11.txt            May 2006

                    |<----- Pseudowire ----->|
                    |                        |
                    |  |<-- PSN Tunnel -->|  |
        ATM Service  V  V                  V  V  ATM Service
            |    +----+                  +----+    |
  +----+    |    | PE1|==================| PE2|    |    +----+
  |    |----------|............PW1.............|----------|    |
  | CE1|    |    |    |                  |    |    |    |CE2 |
  |    |----------|............PW2.............|----------|    |
  +----+    |    |    |==================|    |    |    +----+
        ^          +----+                  +----+    |    ^
        |      Provider Edge 1        Provider Edge 2    |
        |                                                  |
        |<-------------- Emulated Service ---------------->|
  Customer                                                Customer
  Edge 1                                                  Edge 2

                  Figure 1: ATM Service Reference Model

3. Applicability Statement

  The ATM over PW service is not intended to perfectly emulate a
  traditional ATM service, but it can be used for applications that
  need an ATM transport service.

  The following are notable differences between traditional ATM
  service, and the protocol described in this document:

    - ATM cell ordering can be preserved using the OPTIONAL sequence
      field in the control word, however implementations are not
      required to support this feature. The use of this feature may
      impact other ATM quality of service (QoS) commitments.

    - The QoS model for traditional ATM can be emulated. However the
      detailed specification of ATM QoS emulation is outside the scope
      of this document. The emulation must be able to provide the
      required ATM QoS commitments for the end user application.

    - The ATM flow control mechanisms are transparent to the MPLS
      network, and cannot reflect the status of the MPLS network.

    - Control plane support for ATM SVCs SVPs, SPVCs and SPVPs is
      outside the scope of this document.

Martini, et al.                                                [Page 4]
Internet Draft      draft-ietf-pwe3-atm-encap-11.txt            May 2006

4. Terminology

  One-to-one mode: The One-to-one mode specifies an encapsulation
  method which maps one ATM Virtual Channel Connection ( VCC ) (or one
  ATM Virtual Path Connection (VPC) ) to one pseudowire.

  N-to-one mode (N >= 1): The N-to-one mode specifies an encapsulation
  method which maps one or more ATM VCCs (or one or more ATM VPCs) to
  one pseudowire.

  Packet Switched Network - A Packet Switched Network (PSN) is an IP or
  MPLS network.

  Pseudowire Emulation Edge to Edge - pseudowire Emulation Edge to Edge
  (PWE3) is a mechanism that emulates the essential attributes of a
  service (such as a T1 leased line or Frame Relay) over a PSN.

  Customer Edge - A Customer Edge (CE) is a device where one end of a
  service originates and/or terminates. The CE is not aware that it is
  using an emulated service rather than a native service.

  Provider Edge - A Provider Edge (PE) is a device that provides PWE3
  to a CE.

  Pseudowire - A pseudowire (PW) is a connection between two PEs
  carried over a PSN. The PE provides the adaptation between the CE and
  the PW.

  Pseudowire PDU - A pseudowire PDU is a PDU sent on the PW that
  contains all of the data and control information necessary to provide
  the desired service.

  PSN Tunnel - A PSN Tunnel is a tunnel inside which multiple PWs can
  be nested so that they are transparent to core PSN devices.

  PSN Bound - The traffic direction where information from a CE is
  adapted to a PW, and PW-PDUs are sent into the PSN.

  CE Bound - The traffic direction where PW-PDUs are received on a PW
  from the PSN, re-converted back in the emulated service, and sent out
  to a CE.

  Ingress - The point where the ATM service is encapsulated into a
  pseudowire PDU (ATM to PSN direction.)

  Egress - The point where the ATM service is decapsulated from a
  pseudowire PDU (PSN to ATM direction.)

Martini, et al.                                                [Page 5]
Internet Draft      draft-ietf-pwe3-atm-encap-11.txt            May 2006

  CTD -  Cell Transfer Delay

  MTU -  Maximum Transmission Unit

  OAM -  Operations And Maintenance.

  PVC -  Permanent Virtual Connection. An ATM connection that is
  provisioned via a network management interface.  The connection is
  not signaled.

  VCC - Virtual Circuit Connection. An ATM connection that is switched
  based on the cell header's VCI.

  VPC - Virtual Path Connection. An ATM connection that is switched
  based on the cell header's VPI.

  Additional terminology relevant to pseudowires and Layer 2 Virtual
  Private Networking (L2VPN) in general may be found in [RFC4029].

5. General encapsulation method

  This section describes the general encapsulation format for ATM over
  PSN 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                        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                    ATM Control Word                          |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                    ATM Service Payload                      |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 2: General format for ATM encapsulation over PSNs

  The PSN Transport Header depends on the particular tunneling
  technology in use. This header is used to transport the encapsulated
  ATM information through the packet switched core.

  The Pseudowire Header identifies a particular ATM service on a
  tunnel. In case of MPLS, the pseudowire header is one or more MPLS
  labels at the bottom of the MPLS label stack.

  The ATM Control Word is inserted before the ATM service payload. It

Martini, et al.                                                [Page 6]
Internet Draft      draft-ietf-pwe3-atm-encap-11.txt            May 2006

  may contain a length and sequence number in addition to certain
  control bits needed to carry the service.

5.1. The Control Word

  The Control Words defined in this section are based on the Generic PW
  MPLS Control Word as defined in [RFC4385]. They provide the ability
  to sequence individual frames on the PW, avoidance of equal-cost
  multiple-path load-balancing (ECMP) [RFC2992], and OAM mechanisms
  including VCCV [VCCV].

  [RFC4385] states, "If a PW is sensitive to packet misordering 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 misordering." This is necessary due to the fact that
  ECMP implementations may examine the first nibble after the MPLS
  label stack to determine whether the labelled packet is IP or not.
  Thus, if the VPI of an ATM connection carried over the PW using N-
  to-one cell mode encapsulation 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 frames on a
  given PW, or cause OAM packets to follow a different path than actual
  traffic (see section 4.4.3 on Frame Ordering).

  The features that the control word provides may not be needed for a
  given ATM PW. For example, ECMP may not be present or active on a
  given MPLS network, strict frame sequencing may not be required, etc.
  If this is the case, and the control word is not REQUIRED by the
  encapsulation mode for other functions such as length or the
  transport of ATM protocol specific information, the control word
  provides little value and is therefore OPTIONAL. Early ATM 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 frames without the control word present.

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

  If the pseudowire traverses a network link that requires a minimum
  frame size such as Ethernet as a practical example, with a minimum
  frame size of 64 octets, then such links will apply padding to the
  pseudowire PDU to reach its minimum frame size. In this case the
  control word must include a length field set to the PDU length. A

Martini, et al.                                                [Page 7]
Internet Draft      draft-ietf-pwe3-atm-encap-11.txt            May 2006

  mechanism is required for the egress PE to detect and remove such
  padding.

5.1.1. The Generic Control Word

  This control word is used in the following encapsulation modes:

    - ATM 1 to 1 Cell Mode
    - AAL5 PDU Frame Mode

  The PWE3 control word document [RFC4385] provides the following
  structure for the generic control word:

    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|          Specified by PW Encapsulation                |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  The detailed structure for the ATM 1 to 1 Cell Mode and for the AAL5
  PDU Frame Mode 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| Resvd |        Sequence Number        | ATM Specific  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  In the above diagram the first 4 bits MUST be set to 0 to indicate PW
  data.  They MUST be ignored by the receiving PE.

  The next four bits are reserved and MUST be set to 0 upon
  transmission and ignored upon reception.

  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.

  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 alghorithm is not used.

  The last 8 bits provide space for carrying ATM specific flags. These
  are defined in the protocol-specific details below.

Martini, et al.                                                [Page 8]
2016-10-27
01 (System) New version approved
2016-10-27
00 (System) Request for posting confirmation emailed to previous authors: "Pierpaolo Giacomin" , "Liang Xia" , "Susan Hares" , "Robert Moskowitz" , "Igor Faynberg"
2016-10-27
00 Robert Moskowitz Uploaded new revision
2016-10-11
00 Robert Moskowitz New version available: draft-moskowitz-ssls-hip-00.txt
2016-10-11
00 (System) New version approved
2016-10-11
00 Robert Moskowitz Request for posting confirmation emailed  to submitter and authors: "Pierpaolo Giacomin" , "Susan Hares" , "Liang Xia" , "Robert Moskowitz" , "Igor Faynberg"
2016-10-11
00 Robert Moskowitz Uploaded new revision