Re: [PWE3] draft-ietf-pwe3-frame-relay-05.txt last call
Stewart Bryant <stbryant@cisco.com> Tue, 31 May 2005 18:18 UTC
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdBJS-0001fM-EV; Tue, 31 May 2005 14:18:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdBJB-0001cL-NB for pwe3@megatron.ietf.org; Tue, 31 May 2005 14:17:45 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03581 for <pwe3@ietf.org>; Tue, 31 May 2005 14:17:42 -0400 (EDT)
Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdBQg-0000NS-EO for pwe3@ietf.org; Tue, 31 May 2005 14:25:33 -0400
Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 31 May 2005 20:05:01 +0200
Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4VI4v7F029943; Tue, 31 May 2005 20:04:58 +0200 (MEST)
Received: from cisco.com (ams-clip-vpn-dhcp4223.cisco.com [10.61.80.126]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id TAA22076; Tue, 31 May 2005 19:04:46 +0100 (BST)
Message-ID: <429CA73D.3080703@cisco.com>
Date: Tue, 31 May 2005 19:04:45 +0100
From: Stewart Bryant <stbryant@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: pwe3 <pwe3@ietf.org>, 'Luca Martini' <lmartini@cisco.com>
Subject: Re: [PWE3] draft-ietf-pwe3-frame-relay-05.txt last call
References: <429C856E.10301@cisco.com>
In-Reply-To: <429C856E.10301@cisco.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 1.1 (+)
X-Scan-Signature: 08156cf414e01129f6a937203576bf20
Content-Transfer-Encoding: 7bit
Cc:
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>, <mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>, <mailto:pwe3-request@ietf.org?subject=subscribe>
Sender: pwe3-bounces@ietf.org
Errors-To: pwe3-bounces@ietf.org
Comments on: draft-ietf-pwe3-frame-relay-05.txt Abstract A frame relay pseudo-wire is a mechanism that exists between a provider's edge network nodes and support as faithfully as possible frame relay services over MPLS packet switched network (PSN). This document describes the detailed encapsulation necessary to transport frame-relay packets over an MPLS network. SB> I prefer the style of the abstract used in Ethernet/ATM etc. SB> Perhaps we should say something like: SB> SB> A Frame Relay Pseudowire (PW) is used to carry Frames Relay SB> over an MPLS network. This enables service providers to SB> offer an "emulated" ethernetFrame Relay service over SB> and existing MPLS packet switched network (PSN). This SB> document describes the detailed encapsulation necessary SB> to transport frame-relay packets over an MPLS network. SB> --------------- - Backward direction. In frame relay it is the direction opposite to the direction taken by a frame being forwarded (see also forward direction). - Forward direction. The forward direction is the direction taken by the frame being forwarded. SB> The <forward> reference to the term is unhelpful :) SB> How about: SB> SB> -Forward direction SB> The forward direction is from the sender to the receiver. SB> i.e. the direction of normal data transfer SB> SB> -Backwards direction is from the receiver to the sender. SB> i.e. the opposite direction to normal data transfer. SB> SB> However I would think that the FRF has a better wording ---------------- 3. Acronyms and Abbreviations L2TP Layer 2 Tunneling Protocol POS Packet over SONET/SDH SB> These are not used in the draft SB> I just checked a couple - need to check that all terms SB> are used in the draft ----------------- 4. Introduction In an MPLS or IP network, it is possible to use control protocols such as those specified in [CONTROL] to set up "Pseudo Wires" that carry the the Protocol Data Units of layer 2 protocols across the network. A number of these emulated Pseudo Wires (PW) may be carried in a single tunnel. SB> Intro should focus on FR, perhaps with callout to [RFC3985] SB> Ref to control is too early in flow of thought. ----------------- The main functions required to support frame relay PW by a PE include: SB> s/include/are/ - Encapsulation of frame relay specific information in a suitable pseudo wire (PW) packet, - Transfer of a PW packet across an MPLS network for delivery to a peer PE. - Extraction of frame relay specific information from a PW packet by the remote peer PE, - Regeneration of native frame relay frames for forwarding across an egress port of the remote peer PE, - Execution of any other operations as required to support frame relay service. SB> last is a bit wooly for a "main function" This document specifies the encapsulation for the emulated frame relay VC over an MPLS PSN. SB> Not sure if the terms section absolves you from defining inline 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] [ETH] [PPP] SB> Not sure the above para add much value. ----------------- Two mapping modes can be defined between frame relay VCs and pseudo wires: The first one is called "one-to-one" mapping, because there SB> s/first one/first/ SB> s/, because there is/. This has/ is a one-to-one correspondence between a frame-relay VC and one SB> s/one/a/ ? Pseudo Wire. The second mapping is called "many-to-one" mapping or "port mode" Because multiple frame-relay VCs assigned to a port are SB> s/Because/. In this mode/ mapped to one pseudo wire. The "port mode" encapsulation is identical SB> You do not define "port mode" above, you mean "one to one" SB> or you could change the name above. to HDLC pseudo wire encapsulation which is described in [PPP]. 5. General encapsulation method The general frame relay pseudo wire packet format for carrying frame relay information (user's payload and frame relay control information) between two PEs is shown in Figure 2. SB> The term General does not seem right. Cant't think of a better SB> but I would read right if you just deleted the word. +-------------------------------+ | | | MPLS Transport header | | (As required) | +-------------------------------+ | Pseudo Wire (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 pseudo wire header. The SB> Above is a strange order of presentation. SB> Also what you call the PW header is the PW demux SB> PW packet is not a precisely defined term. SB> Not sure why we don't use the simpler explaination that SB> you used in Ethernet and HDLC. meaning of the different fields is as follows: -i. MPLS Transport header is specific to the MPLS network. This header is used to switch the PW packet through the MPLS core. -ii. PW header contains an identifier for multiplexing PWs within an MPLS tunnel. -iii. Control Word contains protocol control information for providing a frame relay service. Its structure is provided in the following sections. -iv. The contents of the frame relay service payload field depends on the mapping mode. In general it contains the layer 2 frame relay frame. SB> Doesn't it ALWAYS contain the FR frame less it's FR header? 6. Frame Relay over MPLS PSN for the One-to-One Mode SB> perhaps just "Frame Relay one-to-one Mode"? 6.1. MPLS PSN Tunnel and PW MPLS label switched paths (LSPs) called "MPLS Tunnels" are used between PEs and within the MPLS core network for forwarding purposes of PW packets. A MPLS tunnel corresponds to "PSN Tunnel" of Figure 1. Several "Pseudo-Wires" may be nested inside one MPLS tunnel. Each PW carries the traffic of a single frame relay VC. 6.2. Packet Format over MPLS PSN For the one-to-one mapping mode for frame relay over an MPLS network, SB> one to one is redundant above. the PW packet format is shown in Figure 3. +-------------------------------+ | MPLS Tunnel label(s) | n*4 octets (four octets per label) +-------------------------------+ | PW label | 4 octets +-------------------------------+ | Control Word | | (See Figure 5) | 4 octets +-------------------------------+ | Payload | | (Frame relay frame | | information field) | n octets | | +-------------------------------+ Figure 3 - frame relay Over MPLS PSN Packet for the One-to-One Mapping SB> Capitalise Frame Relay (everywhere) The meaning of the different fields is as follows: SB> s/different// - MPLS Tunnel label(s) The MPLS Tunnel label(s) corresponds to the PSN transport header of Figure 3. The label(s) is/are used by MPLS LSRs to forward a PW packet from one PE to the other. SB> I think that you mean Figure 2, not Figure 3 SB> Perhaps from ingress PE to egress PE - PW Label The PW label identifies one PW (i.e. one LSP) assigned to a frame SB> Provides PW multiplexing? relay VC in one direction. It corresponds to the PW header of Figure 3. Together the MPLS Tunnel label(s) and PW label form an SB> again figure 2 MPLS label stack [RFC3032]. - Control Word The Control Word contains protocol control information. Its structure is shown in Figure 4. - Payload The payload field corresponds to X.36/X.76 frame relay frame information field with bit/byte stuffing, frame relay header removed, and FCS removed . 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. [CONTROL] SB> This IS acheived by using the MTU i/f param, or it is manually SB> configured. 6.3. The Control Word When carrying frame relay over an MPLS network, sequentiality may need to be preserved. SB> I think that you need to talk about sequentiallity later SB> The FBDC bits are a MUST so you ought to talk about them first SB> since they make the CW required. Should ref the CW draft. The REQUIRED control word defined here addresses this requirement. The Control Word contains protocol control information. Its structure is as follows: SB> Actually its definition is shown. 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|Res| Length | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4 - Control Word structure for the one-to-one mapping mode The meaning of the Control Word fields (Figure 5) is as follows (see also [X36 and X76] for frame relay bits): SB> Do you mean for the definition of FBDC bits? - bits 0 to 3 In the above diagram the first 4 bits MUST be set to 0 to indicate PW data. SB> [CW]? - F (bit 4) FR FECN (Forward Explicit Congestion Notification) bit. - B (bit 5) FR BECN (Backward Explicit Congestion Notification) bit. - D (bit 6) FR DE bit (Discard Eligibility) bit. - C (bit 7) FR frame C/R (Command/Response) bit. - Res (bits 8 and 9): These bits are reserved and MUST be set to 0 upon transmission and ignored upon reception. - Length (bits 10 to 15) If the Pseudo Wire 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 SB> Which frame? SB> This is not expressed very clearly. The above sounds as if the SB> PW has to introduce the padding. (defined as the length of the layer 2 payload plus the length of SB> Frame Relay payload? 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. SB> I think that the length text needs to be changed to be more SB> precise terminology. - 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 SB> circular space that omits zero? indicate that the sequence number check algorithm is not used. 6.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. SB> You could make an informative reference to the Martini draft. 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|Res| Length | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note that the "B" and "F" bits are reversed. This control word format is used for PW type "Frame Relay DLCI ( Martini Mode )" 6.5. PW packet processing 6.5.1. Generation of PW packets The generation process of a PW packet is initiated when a PE receives a frame relay frame from one of its frame relay UNI or NNI interfaces. The PE generates the following fields of the Control word from the corresponding fields of the frame relay frame as follows: - Command/Response (C/R or C) bit: The C bit is copied unchanged in the PW Control Word. - 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 not already set by the copy operation, setting of this bit by a PE is OPTIONAL. SB> I don't think that you need the above sentence - you already said SB> That the bit was copied, and then you you used a MAY The PE MUST NOT clear this bit (set it to 0 if it was received with the value of 1). SB> You could also think of expressing it more formally via a local SB> variable indicating congestion state and an OR operation. SB> line break needed here SB> Same comments apply to other bits SB> Also we are not precise enought with the bit names SB> are they the F bit, the FR FECN bit or the FECN bit. SB> should be clear what we are going to call them. SB> If the issue is the space in the CW, you could use SB> the arrow method to associate name and bit. - 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 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). - 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 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). - 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. - The sequence number field is processed if the PW uses sequence numbers. - 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. 6.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 following procedures should be used: - the initial packet transmitted on the PW MUST use sequence number 1 - subsequent packets MUST increment the sequence number by one for each packet - when the transmit sequence number reaches the maximum 16 bit value (65535) the sequence number MUST wrap to 1 If the transmitting router PE1 does not support sequence number processing, then the sequence number field in the control word MUST be set to 0. SB> Perhaps the earlier SN text should just point here rather SB> than saying the same thing twice? 6.6. Reception of PW packets When a PE receives a PW packet, it processes the different fields of the control word in order to generate a new frame relay frame for SB> it uses the information contained in the CW to regenerate the ? transmission to a CE on a frame relay UNI or NNI. The PE performs the following actions (not necessarily in the order shown): SB> Not sure is the order text adds much value. - It generates the following frame relay frame header fields from the corresponding fields of the PW packet. - The C/R bit is copied in the frame relay header. - The D bit is copied into the frame relay header DE bit. - The F bit is 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. - The B bit is 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. SB> Shouldn't the above be a sub list? SB> Would it be clearer to say copy all the bits, then to say SB> how F and B may be changed. Also see my earlier note about SB> the consistency of the terms - It processes the length and sequence field, the details of which are in the subsequent sub-sections. - It generates 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 generated, the FCS has to be computed, HDLC flags have to be added and any bit or byte stuffing has been performed (these final actions typically take place in a hardware framer). The FR frame is queued for transmission on the selected frame relay UNI or NNI interface. 6.6.1. Processing the sequence number If a router PE2 supports receive sequence number processing, then the following procedures should be used: SB> s/should/SHOULD/? When a PW is initially set up, the "expected sequence number" associated with it MUST be initialized to 1. When a packet is received on that PW, the sequence number should be processed as follows: - if the sequence number on the packet is 0, then the sequence number check is skipped. ( sequence check disabled ) - otherwise if the packet sequence number >= the expected sequence number and the packet sequence number - the expected sequence number < 32768, then the packet is in order. - otherwise if the packet sequence number < the expected sequence number and the expected sequence number - the packet sequence number >= 32768, then the packet is in order. - otherwise the packet is out of order. If a packet passes the sequence number check, or is in order then, it can be delivered immediately. If the packet is in order, then the expected sequence number should be set using the algorithm: SB> should or SHOULD? ------------- 6.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. - If the Length field is set to zero then there are no padding octets following the payload field. - Else if the payload is longer then the length specified in the control word padding characters are removed based on the length field. SB> padding octets ----------- 6.9. Control Plane Details for Frame Relay Service When emulating a frame relay service, the frame relay PDUs are encapsulated according to the procedures defined herein. 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 [ITUQ] 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 [ITUQ] on the egress Frame relay PVC. SB> New para? There are two frame relay flags to control word bit mappings described below. The legacy bit ordering SB> s/below/above/? scheme will be used for a PW of type 0x0001 "Frame Relay DLCI SB> I think that you need to make it clearer that you are talking SB> about PW Type defined in IANA and carried acoding to the SB> control draft. (Martini Mode)", while the new bit ordering scheme will be used for a PW of type 0x0019 "Frame Relay DLCI". SB> Also should define this as the prefered/default mode and SB> put it first in the description The IANA allocation registry of "Pseudowire Type" is defined in [IANA] along with initial allocated values. 6.9.1. Frame-Relay Specific Interface Parameters A separate document [CONTROL], describes the PW control, and maintenance protocol in detail including generic interface parameters. The interface parameter information, when applicable, it 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 [CONTROL], the IANA registry with initial values for interface parameter types is defined in [IANA], but the frame relay specific interface parameters are specified as follows: - 0x08 Frame-Relay DLCI Length. An optional 16 bit value indicating the length of the frame relay SB> 15 bit? DLCI field. This OPTIONAL interface parameter can have value of 2 , or 4, with the default being equal to 2. If this interface parameter is not present the default value of 2 is assumed. 9. 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 give in [RFC3985, CONTROL, PWE3REQ]. SB> s/PWE3REQ/RFC3916/ SB> Not sure whether we will get away with this short text on SB> security. --------------------- 12. Normative References [PPP] "Encapsulation Methods for Transport of PPP/HDLC Over MPLS Networks", draft-ietf-pwe3-hdlc-ppp-encap-05.txt April 2005 SB> I don't think that this needs to be normative Martini, et al. [Page 16] Internet Draft draft-ietf-pwe3-frame-relay-05.txt April 2005 [PWE3REQ] XiPeng Xiao, et al., RFC 3916. SB> should use RFC3916 as the reference _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3
- [PWE3] draft-ietf-pwe3-frame-relay-05.txt last ca… Stewart Bryant
- Re: [PWE3] draft-ietf-pwe3-frame-relay-05.txt las… Stewart Bryant
- Re: [PWE3] draft-ietf-pwe3-frame-relay-05.txt las… Carlos Pignataro
- Re: [PWE3] draft-ietf-pwe3-frame-relay-05.txt las… Luca Martini
- Re: [PWE3] draft-ietf-pwe3-frame-relay-05.txt las… Carlos Pignataro
- Re: [PWE3] draft-ietf-pwe3-frame-relay-05.txt las… Luca Martini