Internet Draft Stewart Bryant
Document: <draft-bryant-pwe3-fr-encap-01.txt> Lloyd Wood
Expires: September 2002 George Wilkie
Cisco Systems
March 2002
A Proposed Frame Relay Encapsulation for PWE3
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress.
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt The list of
Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This draft describes a pseudo-wire emulation edge-to-edge (PWE3)
frame relay encapsulation that conforms to the PWE3 Protocol Layering
proposed by Bryant et al [LAYER], and discuses the services required
from the underlaying PWE3 layers.
Bryant, et al. Informational [Page 1]
INTERNET DRAFT draft-bryant-pwe3-fr-encap-01 March 2002
Table of Contents
1. Introduction............................................. 2
2. Terminology.............................................. 2
3. PW Encapsulation......................................... 3
3.1 Payload Convergence Sub-layer........................ 3
3.2 Payload Independent PW Encapsulation Layers.......... 4
4. PSN Tunnel Layer Requirements............................ 5
4.1 Multiplexing......................................... 5
4.2 Segmentation and Reassembly.......................... 5
4.3 Length and Delivery................................... 5
5. Control Plane............................................ 6
6. IANA considerations...................................... 6
7. Security................................................. 6
Appendix A: Intermediate Formats Considered Harmful.......... 7
1. Introduction
A frame relay pseudo-wire allows frame relay protocol control
information and payloads to be carried over a Packet Switched
Network. This draft describes how our preferred frame relay
encapsulation is carried over the proposed PWE3 protocol layering
model [LAYER], and discusses the services required from the
underlying PWE3 layers.
2. Terminology
The following definitions are used in t his document:
BECN Backward Explicit Congestion Notification
bit in frame relay header.
Bryant, et al. Informational [Page 2]
INTERNET DRAFT draft-bryant-pwe3-fr-encap-01 March 2002
Customer Edge (CE) A device where one end of a service
originates and terminates. The CE is not
aware that it is using an emulated service
rather than a native service.
DE Discard Eligibility bit in frame relay header.
Native Service Processing of the data received by the PE
Processing (NSP) from the CE before presentation to the PW
for transmission across the core.
FECN Forward Explicit Congestion Notification
bit in frame relay header.
Packet Switched A network using IP or MPLS as the mechanism
Network (PSN) of packet forwarding.
Protocol Data The unit of data output to, or received
Unit (PDU) from, the network by a protocol layer.
Provider Edge (PE) A device that provides PWE3 to a CE.
Pseudo Wire (PW) A connection between two PEs carried over
PSN.
Pseudo Wire A mechanism that emulates the essential
Emulation Edge to attributes of service (such as a T1 leased
Edge (PWE3) line or frame relay) over a PSN.
PSN Tunnel A tunnel across a PSN inside which one or
more PWs can be carried.
PWE3 Payload The protocol sub-layers within PWE3
Independent responsible for sequencing and timing.
Sub-layers
3. PW Encapsulation
3.1 Payload Convergence Sub-layer
Frame Relay uses the PWE3 generic packet payload service [LAYER],
employing the principle of minimum intervention. The native frame
relay PDU is transported as received, excluding only HDLC flags and
the frame-check sequence (FCS). Bit stuffing is undone. (This
Bryant, et al. Informational [Page 3]
INTERNET DRAFT draft-bryant-pwe3-fr-encap-01 March 2002
contrasts with the proposal of Kawa et al [KAWA], which uses an
intermediate PW format.)
If the underlying PSN provides a congestion notification service, the
congestion state must to be passed up to the Payload Convergence
Sub-layer by the intermediate layers. The Payload Convergence Sub-
layer may set the frame relay Forward Explicit Congestion
Notification (FECN) bit if the packet has experienced congestion
traveling across the PSN to the destination PE. It may also set the
Backward Explicit Congestion Notification (BECN) bit on frame relay
packets on the reverse path of the same PW.
The encapsulation layer may request the use of different PSN QoS
settings, depending on the setting of the Discard Eligibility (DE)
bit in the frame relay header.
The Emulated Service (as defined in figure 1 of [LAYER]) is
responsible for providing the following frame relay service policies.
o CIR (Committed Information Rate) or throughput.
o Bc (Committed burst size).
o Be (Excess Burst Size).
o Maximum frame size.
Typically, the NSP would be responsible for policing the traffic to
CIR, Bc, Be before passing to the PW. Some indication of the
committed burst size (which should get guaranteed delivery) and the
excess burst size (which may be delivered with lower probability)
would be provided by the NSP to the PW. The PW and the remote NSP are
then responsible for ensuring that committed traffic arrives at the
remote CE. In other implementations, typically those operating over a
high bandwidth core, all the service policy processing could be
delegated to the destination PE.
If the frame relay PDU conforms to the maximum frame size, but the PW
encapsulated frame relay PDU exceeds the PSN maximum PDU length, the
segmentation and reassembly considerations described in [LAYER] are
followed.
3.2 Payload Independent PW Encapsulation Layers
Frame Relay requires the use of sequencing from the payload
independent encapsulation layer to maintain packet order, which is an
invariant of Frame Relay networks.
In some cases, the protocol carried over the frame relay VC is known
to be insensitive to packet order (for example if the traffic is
KNOWN to be IP), in which case there may be a desire to reduce the
Bryant, et al. Informational [Page 4]
INTERNET DRAFT draft-bryant-pwe3-fr-encap-01 March 2002
overhead associated with the transmission and receive processing of
ordered packets. The use of the sequencing service is therefore
optional.
The encapsulation of frame relay has no timed delivery or clock
recovery requirements. It therefore does not use the PWE3 Timing
Sublayer.
4. PSN Tunnel Layer Requirements
4.1 Multiplexing
The frame relay Encapsulation Layer depends on the multiplexing
functionality in the PSN Tunnel Layer to provide multiple PWs between
PEs. There are two types of frame relay PW:
o Trunks, in which multiple frame relay VCs are sent over the PW.
The normal usage of this is where all traffic on a physical
interface to the PE is sent over the PW to a corresponding
physical interface on the destination PE.
A PE may contain an NSP that provides a frame relay switch
function, and presents a frame relay trunk to the PW
Encapsulation Layer via a virtual interface.
o Single DLCI, in which the PW carries just the traffic of a
single VC.
4.2 Segmentation and Reassembly
It is desirable that the MTU of the frame-relay packets received from
the CE is constrained so that the packets can be carried over the PSN
without fragmentation. If this is not possible, the segmentation and
reassembly service of the underlying PSN is used.
4.3 Length and Delivery
The underlying PSN is responsible for determining the correct length
of a frame relay PDU and delivering the PDU to the PSN Tunnel Layer.
Bryant, et al. Informational [Page 5]
INTERNET DRAFT draft-bryant-pwe3-fr-encap-01 March 2002
5. Control Plane
Mechanisms are needed to set up and tear down frame relay PWs and to
carry PVC status across the PW.
An example of the necessary extensions needed to support a frame
relay PW across an L2TP PSN tunnel is given in [TOWNSLEY].
Aspects of the PW control plane specific to frame relay form a work
area that needs further study.
6. IANA considerations
IANA considerations are for further study.
7. Security
PWE3 provides no means of protecting the contents or delivery of the
PDU's on behalf of the native service. PWE3 may, however, leverage
security mechanisms provided by the PSN Tunnel Layer.
A more detailed discussion of PW security is give in [LAYER].
References
Internet-drafts are works in progress available from
<http://www.ietf.org/internet-drafts/>
[KAWA] Kawa et al, Frame relay over Pseudo-Wire Emulation Edge-to-Edge,
<draft-kamapabhava-fr-pwe3-00.txt>, work in progress
[LAYER] Bryant et al, Protocol Layering in PWE3,
<draft-bryant-pwe3-protocol-layering-01.txt>, work in progress
[MARTINI] L. Martini, Tappan, D., et al. 'Encapsulation Methods for
Transport of Layer 2 Frames Over IP and MPLS Networks', work in
progress as an internet-draft:
<draft-martini-l2circuit-encap-mpls-03.txt>, work in progress
Bryant, et al. Informational [Page 6]
INTERNET DRAFT draft-bryant-pwe3-fr-encap-01 March 2002
[Q.922] ITU-T Recommendation Q.922, ISDN Data Link Layer
Specification for Frame Mode Bearer Services, ITU, Geneva, 1992.
[Q933] ITU-T Recommendation Q.933, ISDN Signaling Specification
for Frame Mode Bearer Services, Geneva, October 1995.
[TOWNSLEY] Townsley et al, Frame-Relay Pseudo-Wire Extensions
for L2TP <draft-ietf-l2tpext-pwe3-fr-00.txt>, work in progress
Appendix A: Intermediate Formats Considered Harmful
The design of the pseudo-wire encapsulation header can have
considerable impact on the performance of the system using it.
The most computationally-efficient encapsulation approach is the
use of the PWE3 generic packet payload service [LAYER], which
is the approach that we propose in this draft. This approach
conforms to the principle of minimum intervention, and is
is similar to the general pseudo-wire encapsulation approach
proposed by [MARTINI] for HDLC, Ethernet and VLAN.
This appendix analyses the computational efficiency gain of the
generic packet approach, and demonstrates the relative
efficiency of the generic packet approach.
A.1 The Martini Frame Relay Encapsulation
[MARTINI] takes the approach of copying the frame relay payload-
dependent bits to fields in a the control word, stripping the frame
Relay header from the fame Relay PDU, and reconstructing the header
at the far end of the pseudo-wire. The reason for this approach is
not given in [MARTINI].
The layout and ordering of the B, F, D and C bits in the control
word differ from the layout and ordering of these bits in the frame
Relay header. This results in unnecessary bit manipulation in both
encapsulation and decapsulation and introduces unnecessary processing
overhead in any implementation.
The control word defined in [MARTINI] is:
Bryant, et al. Informational [Page 7]
INTERNET DRAFT draft-bryant-pwe3-fr-encap-01 March 2002
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rsvd |D|B|F|C| Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The two-octet frame relay header in normal IETF (DoD) notation is:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| hi dlci |C|0|lo dlci|F|B|D|1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
C = FR frame C/R (command/response) bit [Q.922].
F = FECN (Forward Explicit Congestion Notification) bit [Q.922].
B = BECN (Backward Explicit Congestion Notification) bit [Q.922].
D = DE indicates the Discard Eligibility [Q922].
Frame relay header bits 7 and 15 are the Q.922 EA (Extended Address)
bits used for address field extension. In the unextended two-octet
header these are defined to be 0 and 1 respectively.
Processors rarely have efficient bit manipulation operations, so you
cannot normally just assign the bits to their new positions easily.
It therefore becomes necessary to isolate each of the DBFC bits in
the control word using an AND operation, to use a shift operator to
move each bit to its correct position in the frame relay header, and
then to load the isolated bit into the header buffer using an OR
operator. This requires four operations on each of four bits:
- Move first octet of control word to temporary location.
- AND to isolate bit.
- Shift bit to corresponding location in frame relay header octet.
- Write or OR bit into frame relay header.
A similar number of operations in needed in constructing the Control
Word from the received frame relay header. For comparison we can
regard this construction as having a cost of: (4 bits * 4
operations) + (4 bits * 4 operations) = 32 operations.
Note that we have not included the processing of the DLCI bits
(normally an OR operation) in this analysis, since that is an
overhead common to all transmission formats. Also note that, for the
Bryant, et al. Informational [Page 8]
INTERNET DRAFT draft-bryant-pwe3-fr-encap-01 March 2002
purposes of frame relay header manipulation, the EA bits can normally
be included in the pro-forma DLCI definition.
A.2 The Kawa encapsulation
As with the [MARTINI] approach, the frame relay payload-dependent
bits are copied to fields in a control word, the frame relay header
is stripped from the frame relay PDU, and the header is reconstructed
at the far end of the pseudo-wire. Again, the reason for doing this
is not given. It has been proposed that [KAWA] be changed to follow
the [MARTINI] control word, but at the time of writing this updated
approach has not yet been published.
The grouping and ordering of the payload-dependent bits in the [KAWA]
control word is more consistent with Q.922, allowing them to be
processed as a three bit group (FBD) and a single bit (C). This
reduces the processing overhead in comparison with [MARTINI].
However, the [KAWA] draft fails to take advantage of the additional
performance gains to be made by closely following the layout
specified in [Q.922].
The Kawa control word is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Res |P|F|B|D|C|X|Y| Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Again for comparison, the two-octet frame relay header in normal IETF
(DoD) notation is:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| hi dlci |C|0|lo dlci|F|B|D|1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In this case we can isolate the FBD bits as group, and knowing that
they are in the same position and order in the octet in both Control
Word and the frame relay header, we can write them directly to the
header buffer in three operations:
- Move first octet of control word to temporary location.
- AND to isolate FBD bits.
- Write bits into frame relay header.
The C bit requires isolation with an AND operator, shifting and
Bryant, et al. Informational [Page 9]
INTERNET DRAFT draft-bryant-pwe3-fr-encap-01 March 2002
writing into the header buffer (4 operations).
- Move second octet of control word to temporary location.
- AND to isolate C bit.
- Shift bit to corresponding location in frame relay header octet.
- Write C bit into frame relay header.
This same number of operations is needed in construction of the
control word making a comparative cost of: (3 + 4) + (3 + 4)
operations = 14 operations.
14 operations compares well with the 32 operations needed for the
[MARTINI] implementation.
A.3 Cost of using PWE3 Generic Packet Payload
The use of the general pseudo-wire encapsulation technique as
proposed in this document has a frame relay header bit processing
cost of zero. It is therefore the most processor-efficient approach.
A.4 Frame Relay Header Translation
A common justification for the use of an intermediate format for the
transmission of a frame relay datagram across a PW is the need to
translate the header from one format to another.
There are two frame relay header formats in common use: the two-
octet version used in the examples in this draft, and the four-octet
version.
If the intermediate format is used, the encapsulator has to implement
two cases (two-octet to intermediate and four-octet to intermediate),
and the decapsulator has to implement two cases (intermediate to
two-octet, and intermediate to four-octet). If the frame is
transmitted across the pseudo-wire un-translated, then there are
three translation cases (Nothing, 2->4 and 4->2). This results in a
net reduction in translation and implementation complexity, and an
increase in performance.
It is useful to review the memory organization of the two-octet and
four-octet frame relay headers, to fully appreciate the complexity of
the translation operation. In normal IETF notation, the two-octet
frame relay header is:
Bryant, et al. Informational [Page 10]
INTERNET DRAFT draft-bryant-pwe3-fr-encap-01 March 2002
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| hi dlci |C|0|lo dlci|F|B|D|1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
and the four-octet frame relay header is
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| hi dlci |C|0| dlci |F|B|D|0| dlci |0| dlci_lo |0|1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Bit 30 is the D/C bit. This is set to zero to indicate that the last
octet contains DLCI, rather than control, information.
As can be seen by inspecting these definitions, the translation of a
two-octet frame relay header to a four-octet frame relay header is a
relatively simple operation requiring.
- Move first word of the header to temporary location.
- AND to clear bit 15 (EA = 0).
- Write word into frame relay header at new buffer offset.
Correct setting of the remaining EA bits (bits 23 and 31) and the
DLCI Core indicator (D/C) bit (bit 30) can be considered an integral
part of writing the least significant thirteen bits of the DLCI.
Translation from a two-octet frame relay header to a four-octet frame
relay header has similar complexity:
- Move first word of the header to temporary location.
- OR to set bit 15 (EA = 0).
- Write word into frame relay header at new buffer offset.
Given the simplicity of the frame relay header translation process,
they would seem to be no justification for the use of an intermediate
PW format for the frame relay header.
Bryant, et al. Informational [Page 11]
INTERNET DRAFT draft-bryant-pwe3-fr-encap-01 March 2002
Authors' Addresses
Stewart Bryant
Cisco Systems,
4, The Square,
Stockley Park,
Uxbridge UB11 1BL, Email: stbryant@cisco.com
United Kingdom. Phone: +44-20-8756-8828
George Wilkie
Cisco Systems
96 Commercial Street,
Leith,
Edinburgh, EH6 6LX
United Kingdom Email: gwilkie@cisco.com
Lloyd Wood
Cisco Systems,
4, The Square,
Stockley Park,
Uxbridge UB11 1BL, Email: lwood@cisco.com
United Kingdom. Phone: +44-20-8734-4236
Bryant, et al. Informational [Page 12]
INTERNET DRAFT draft-bryant-pwe3-fr-encap-01 March 2002
Full copyright statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Bryant, et al. Informational [Page 13]