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 |