From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Shahriar Rahman Subject: Padding for ATM cell relay in PW Date: Mon, 6 Jan 2003 10:22:00 -0800 (PST) Lines: 48 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-path: To: pwe3@ietf.org Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Hi, I'm trying to understand padding and usage of the length field of ATM control word in PWE3. The original(and the subsequent drafts) specify that- "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 non- zero, can be used to remove any padding. When the packet reaches the service provider's egress router, it may be desirable to remove the padding before forwarding the packet." in Section "3.1. The Control Word" of draft-martini-l2circuit-encap-mpls-04.txt. Now, an ATM cell is 52B (without HEC), adding control word makes it 56B, which is still under 64B. This means, logically, I would populate the length field in control word on the ingress LSR. I would then use this value to remove any padding added by the PW on the egress LSR. I'm trying to find some scenario when PW will be adding padding. The drafts give Ethernet as an example. However, adding 14B of Ethernet header would mean the L2-header + Control word + Payload would make it more than 64B, which is the minimum frame size for Ethernet (plus the labels for MPLS). So, I conclude that there was no padding even though the control word length field is non-zero. My question is, what should egress LSR do in this case? Ignore the 'length' value or still apply pad removal procedure assuming pad is added when 'length' is non-zero? Is there any mechanism to detect whether any padding has really been added by the PW? Or may be there is something I'm missing here. What could be an example scenario where the control word will have a positive 'length' value and padding would be added by PW in cell relay? Finally, if we assume that there are scenarios where padding is definitely added by the PW, how can we detect that at the egress LSR when there is no control word (since it is optional for cell mode AToM)? Thanks & regards, Shahriar ================================================================= Shahriar Rahman || || Software Engineer |||| |||| c7600 Toaster Development ..:||||||:..:||||||:.. (408) 525 1351 ------------------------ From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Sasha Vainshtein Subject: RE: Padding for ATM cell relay in PW Date: Mon, 6 Jan 2003 20:57:56 +0200 Lines: 108 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" Cc: pwe3@ietf.org Return-path: To: "'Shahriar Rahman'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Shahriar and all, Several comments to your message: 1. In the "general" case, the ingress PE should not take into account either the L2-specific header size or the transport header size (which may change, e.g., if you use a transport LSP with PHP) for filling the Length field in the CW (because changes from hop to hop), and padding may occur at any hop. Hence, formally speaking, a packet containing just one cell should carry the payload Length (52) in its Length field. 2. However, it is worth noting that, in case of ATM cell relay, the packet payload size can only change by steps of 52 (or 49 in alternative encapsulation modes). In other words, IMHO, as long as padding occurs only for packets that do not exceed 64 bytes, you can always know how many ATM cells your packet contains without referring to the Length field - even if the packet has been padded in transit. And of course, if we ever encounter a L2 that pads larger packets (say, less than 128 bytes), the Length field in the Martini CW will not work either. With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) > -----Original Message----- > From: Shahriar Rahman [mailto:sharahma@cisco.com] > Sent: Monday, January 06, 2003 8:22 PM > To: pwe3@ietf.org > Subject: [PWE3] Padding for ATM cell relay in PW > > > > Hi, > I'm trying to understand padding and usage of the length field of ATM > control word in PWE3. The original(and the subsequent drafts) specify > that- > > "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 non- > zero, can be used to remove any padding. When the packet > reaches the > service provider's egress router, it may be desirable to remove the > padding before forwarding the packet." > > in Section "3.1. The Control Word" of > draft-martini-l2circuit-encap-mpls-04.txt. Now, an ATM cell is 52B > (without HEC), adding control word makes it 56B, which is > still under 64B. > This means, logically, I would populate the length field in > control word > on the ingress LSR. I would then use this value to remove any padding > added by the PW on the egress LSR. > > I'm trying to find some scenario when PW will be adding padding. The > drafts give Ethernet as an example. However, adding 14B of > Ethernet header > would mean the L2-header + Control word + Payload would make > it more than > 64B, which is the minimum frame size for Ethernet (plus the labels for > MPLS). So, I conclude that there was no padding even though > the control > word length field is non-zero. My question is, what should > egress LSR do > in this case? Ignore the 'length' value or still apply pad removal > procedure assuming pad is added when 'length' is non-zero? Is > there any > mechanism to detect whether any padding has really been added > by the PW? > Or may be there is something I'm missing here. > > What could be an example scenario where the control word will have a > positive 'length' value and padding would be added by PW in > cell relay? > > Finally, if we assume that there are scenarios where padding > is definitely > added by the PW, how can we detect that at the egress LSR > when there is > no control word (since it is optional for cell mode AToM)? > > Thanks & regards, > Shahriar > > ================================================================= > Shahriar Rahman || || > Software Engineer |||| |||| > c7600 Toaster Development ..:||||||:..:||||||:.. > (408) 525 1351 ------------------------ > > > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Shahriar Rahman Subject: Re: Padding for ATM cell relay in PW Date: Mon, 6 Jan 2003 11:52:04 -0800 (PST) Lines: 62 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: pwe3@ietf.org Return-path: To: Lloyd Wood In-Reply-To: Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Agreed. But it is part of the frame that goes out on the wire in an Ethernet network. And the requirement is to be this number (the entire frame) to be 64B or greater. thanks, Shahriar On Mon, 6 Jan 2003, Lloyd Wood wrote: > On Mon, 6 Jan 2003, Shahriar Rahman wrote: > > > I'm trying to understand padding and usage of the length field of ATM > > control word in PWE3. The original(and the subsequent drafts) specify > > that- > > > > "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 non- > > zero, can be used to remove any padding. When the packet reaches the > > service provider's egress router, it may be desirable to remove the > > padding before forwarding the packet." > > > > in Section "3.1. The Control Word" of > > draft-martini-l2circuit-encap-mpls-04.txt. Now, an ATM cell is 52B > > (without HEC), adding control word makes it 56B, which is still under 64B. > > This means, logically, I would populate the length field in control word > > on the ingress LSR. I would then use this value to remove any padding > > added by the PW on the egress LSR. > > > > I'm trying to find some scenario when PW will be adding padding. The > > drafts give Ethernet as an example. However, adding 14B of Ethernet header > > would mean the L2-header + Control word + Payload would make it more than > ^^^^^^^^^ > > The L2 header is not part of the L2 payload. > > L. > > > 64B, which is the minimum frame size for Ethernet (plus the labels for > > MPLS). So, I conclude that there was no padding even though the control > > word length field is non-zero. My question is, what should egress LSR do > > in this case? Ignore the 'length' value or still apply pad removal > > procedure assuming pad is added when 'length' is non-zero? Is there any > > mechanism to detect whether any padding has really been added by the PW? > > Or may be there is something I'm missing here. > > > > What could be an example scenario where the control word will have a > > positive 'length' value and padding would be added by PW in cell relay? > > > > Finally, if we assume that there are scenarios where padding is definitely > > added by the PW, how can we detect that at the egress LSR when there is > > no control word (since it is optional for cell mode AToM)? > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Eric Rosen Subject: Re: Padding for ATM cell relay in PW Date: Mon, 06 Jan 2003 15:13:51 -0500 Lines: 11 Sender: pwe3-admin@ietf.org References: Reply-To: erosen@cisco.com Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Cc: pwe3@ietf.org Return-path: To: Shahriar Rahman In-reply-to: Your message of Mon, 06 Jan 2003 10:22:00 -0800. User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > However, adding 14B of Ethernet header would mean the L2-header + Control > word + Payload would make it more than 64B, which is the minimum frame > size for Ethernet (plus the labels for MPLS). So, I conclude that there > was no padding even though the control word length field is non-zero. If it is not necessary to add padding when transmitting on ethernet, then the control word's length field should be set to zero. It is an error if the documents state otherwise. In particular, I think the length word should be zero in ATM cell mode, since, as you point out, if you're carrying an entire ATM cell you won't have to add any padding for ethernet. From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Shahriar Rahman Subject: Re: Padding for ATM cell relay in PW Date: Mon, 6 Jan 2003 12:37:45 -0800 (PST) Lines: 42 Sender: pwe3-admin@ietf.org References: <200301062013.h06KDpFp022449@sj-msg-core-1.cisco.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: pwe3@ietf.org Return-path: To: Eric Rosen In-Reply-To: <200301062013.h06KDpFp022449@sj-msg-core-1.cisco.com> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Hi Eric, My concern was regarding the fact that control word's length field contains the L2 payload + control word length. However, in several cases, padding is added to a frame if the entire frame going out on the wire doesn't meet the minimum requirement imposed by the network in question. Ethernet for example. This implies that you would have to compare the packet length with control word's length field on egress LSR in order to detect if any padding has been added. In ATM cell mode, if the length field should be zero when the entire ATM cell is carried in a single frame and the network is Ethernet, then that means you would have to unconditionally make is zero in cell mode ATM when this condition is detected. I don't think the 'spec' states this explicitly as I see cell mode ATM as a special case for control word length field when compared to the frame mode ATM or frame relay. Perhaps making it explicit that the length field should be non-zero when (L2 payload + control word length < 64B) && (padding is added) would clarify it. regards, Shahriar On Mon, 6 Jan 2003, Eric Rosen wrote: > > > However, adding 14B of Ethernet header would mean the L2-header + Control > > word + Payload would make it more than 64B, which is the minimum frame > > size for Ethernet (plus the labels for MPLS). So, I conclude that there > > was no padding even though the control word length field is non-zero. > > If it is not necessary to add padding when transmitting on ethernet, then > the control word's length field should be set to zero. It is an error if > the documents state otherwise. In particular, I think the length word > should be zero in ATM cell mode, since, as you point out, if you're carrying > an entire ATM cell you won't have to add any padding for ethernet. > > > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Shahriar Rahman Subject: RE: Padding for ATM cell relay in PW Date: Mon, 6 Jan 2003 12:50:57 -0800 (PST) Lines: 45 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: pwe3@ietf.org Return-path: To: Sasha Vainshtein In-Reply-To: Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Hi Sasha, Please read inline... On Mon, 6 Jan 2003, Sasha Vainshtein wrote: > Shahriar and all, > Several comments to your message: > 1. In the "general" case, the ingress PE should not take into > account either the L2-specific header size or the transport > header size (which may change, e.g., if you use a transport LSP > with PHP) for filling the Length field in the CW (because changes > from hop to hop), and padding may occur at any hop. > Hence, formally speaking, a packet containing just one cell should > carry the payload Length (52) in its Length field. This contradicts with Eric's response. If padding occurs in any intermediate hop on the PW, it shouldn't be reflected in the CW length field. This field should be touched by ingress and egress edge devices only. Though you are right to say that L2 header should not be included in the length field (and the spec makes it clear), control word length should be included since it is carried across the PW. Hence, the length field could contain 56 according to the spec. However, as Eric pointed out, I think single ATM cell mode is a special case and it should be stated explicitly in the draft. Currently, draft-martini-frame-encap-mpls-01.txt describes the padding procedure in detail. > 2. However, it is worth noting that, in case of ATM cell relay, > the packet payload size can only change by steps of 52 (or 49 > in alternative encapsulation modes). > In other words, IMHO, as long as padding occurs only > for packets that do not exceed 64 bytes, you can always know > how many ATM cells your packet contains without referring to the Length > field - even if the packet has been padded in transit. And of course, > if we ever encounter a L2 that pads larger packets (say, less than 128 > bytes), the Length field in the Martini CW will not work either. For multiple cells, the length field will certainly be zero. So, I don't see any need to use this for that case. Is there any L2 network that pads 128B or less packets? regards, Shahriar From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Eric Rosen Subject: Re: Padding for ATM cell relay in PW Date: Mon, 06 Jan 2003 16:12:02 -0500 Lines: 41 Sender: pwe3-admin@ietf.org References: Reply-To: erosen@cisco.com Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Cc: pwe3@ietf.org Return-path: To: Shahriar Rahman In-reply-to: Your message of Mon, 06 Jan 2003 12:37:45 -0800. User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > Perhaps making it explicit that the length field should be non-zero when > (L2 payload + control word length < 64B) && (padding is added) would > clarify it. The problem is that you set the length field when you create the PWE3 packet, and you don't know for sure whether padding will have to be added somewhere down the line. But it's safe to set it to zero if you know that padding will never have to be added. Your observation, I think, is that it is safe to set it to zero if (L2 payload length >= 48 bytes), since two bytes of control word plus a minimum ethernet header would result in a 64 byte ethernet frame, and padding wouldn't be needed. In any event, when decapsulating, you can't assume that padding is present, even if the length field is non-zero, but you don't really care whether padding is present, you only care about the length of the payload. Probably the length field should have been defined as "if the length of the L2 payload is 48 or more bytes, then 0, else the length of the L2 payload". However, the current definition (which is really "if the length of the L2 payload is 62 or more bytes, then 0, else 2 + the length of the L2 payload", I think) does work. I think your real question was: > So, I conclude that there was no padding even though the control word > length field is non-zero. My question is, what should egress LSR do in > this case? Ignore the 'length' value or still apply pad removal procedure > assuming pad is added when 'length' is non-zero? If the length field, is non-zero, it does allow you to correctly deduce the length of the L2 payload, whether padding is present or not, so I don't think this is an issue. Note that what I am saying here is slightly different than what I said in my previous message ;-) Perhaps the length field should be defined as follows: If the L2 payload is 48 bytes or greater, the length field MAY be set to 0; if the L2 payload is 62 bytes or greater, the length field MUST be set to 0; otherwise the length field is set to 2 plus the length of the L2 payload. This preserves interoperability with the Martini docs while allowing the use of 0 in ATM cell mode. From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Shahriar Rahman Subject: Re: Padding for ATM cell relay in PW Date: Mon, 6 Jan 2003 14:29:29 -0800 (PST) Lines: 65 Sender: pwe3-admin@ietf.org References: <200301062112.h06LC2Fp021915@sj-msg-core-1.cisco.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: pwe3@ietf.org Return-path: To: Eric Rosen In-Reply-To: <200301062112.h06LC2Fp021915@sj-msg-core-1.cisco.com> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Hi Eric, Thanks for the elaborate response. Please read inline.... > > Perhaps making it explicit that the length field should be non-zero when > > (L2 payload + control word length < 64B) && (padding is added) would > > clarify it. > > The problem is that you set the length field when you create the PWE3 > packet, and you don't know for sure whether padding will have to be added > somewhere down the line. But it's safe to set it to zero if you know that > padding will never have to be added. Your observation, I think, is that it > is safe to set it to zero if (L2 payload length >= 48 bytes), since two > bytes of control word plus a minimum ethernet header would result in a 64 > byte ethernet frame, and padding wouldn't be needed. This is exactly what I was pointing at. My observation is that sending a non-zero length field will help extracting the L2 packet at the egress PE device. It doesn't really facilitate detecting padding alone. Another minor thing is control word is 4 bytes. one more thing is that there will almost certainly be PW header(s) added, e.g. MPLS labels, which will make 48 (or 46 for that matter) no longer a safe number to assume. > In any event, when decapsulating, you can't assume that padding is present, > even if the length field is non-zero, but you don't really care whether > padding is present, you only care about the length of the payload. Agreed, as I explained above. > Probably the length field should have been defined as "if the length of the > L2 payload is 48 or more bytes, then 0, else the length of the L2 payload". > However, the current definition (which is really "if the length of the L2 > payload is 62 or more bytes, then 0, else 2 + the length of the L2 payload", > I think) does work. I think your real question was: > > > So, I conclude that there was no padding even though the control word > > length field is non-zero. My question is, what should egress LSR do in > > this case? Ignore the 'length' value or still apply pad removal procedure > > assuming pad is added when 'length' is non-zero? > > If the length field, is non-zero, it does allow you to correctly deduce the > length of the L2 payload, whether padding is present or not, so I don't > think this is an issue. > > Note that what I am saying here is slightly different than what I said in my > previous message ;-) Hmmmm.... looks like it. > Perhaps the length field should be defined as follows: If the L2 payload is > 48 bytes or greater, the length field MAY be set to 0; if the L2 payload is > 62 bytes or greater, the length field MUST be set to 0; otherwise the length > field is set to 2 plus the length of the L2 payload. This preserves > interoperability with the Martini docs while allowing the use of 0 in ATM > cell mode. I believe so with the correction of 4 bytes control word. The PW header can be ignored for all practical purposes as it may be variable. For example, we may not know how may labels (in MPLS case) could always be there to traverse the PW. regards, Shahriar From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: "Peter Reed" Subject: RE: Padding for ATM cell relay in PW Date: Mon, 6 Jan 2003 15:26:06 -0800 Lines: 120 Sender: pwe3-admin@ietf.org References: <200301062112.h06LC2Fp021915@sj-msg-core-1.cisco.com> Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: Return-path: To: , "Shahriar Rahman" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-Reply-To: <200301062112.h06LC2Fp021915@sj-msg-core-1.cisco.com> Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O I think a general re-write of the 'Length' field may be in order. In "draft-ietf-pwe-atm-encap-0.txt", Section 6.5 it states: "The one-octet Length indicates length of the packet payload that includes, length of length field, Sequence number length, the ATM specific header length and the payload length. ... If the PW 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 PW PDU to reach its minimum size...." Issues: 1) draft-ietf-pwe-atm-encap-0.txt, Section 6.5 states the Length Field is one-octet in length not 6 bits, as indicated in "draft-ietf-pwe3-protocol-layer-00.txt" and other IETF drafts. Page 6 of "draft-ietf-pwe-atm-encap-0.txt" shows the Length field as 6-bits longs, which is in conflict with Section 6.5 et al of the same document. 2) In the "draft-ietf-pwe-atm-encap-00.txt" on page 6 the un-titled control word figure shows the Length Field starting in bit position 10 (consistent with draft-ietf-pwe3-protocol-layer-00.txt), while Figures 2, 3, 4, 5, 6, 10 indicates a different bit ordering. Is the length field 6 or 8 bits in length for these modes? What is the ordering (e.g. length/sequence/flag or sequence/length/flag)? 3) Figure 8, draft-ietf-pwe-atm-encap-0.txt, is indeterminate about the structure of the control word. Given that this section looks very similar to the Cell Mode description in "draft-martini-l2circuit-encap-mpls-04.txt" my guess is the length field is 6-bits long and the bit ordering is same as shown on page 6. But as there are multiple structures of the control word shown in this document it would be best to spell this out. 4) The email thread by authors of the IETF draft conflict with the information contained within it, which gives me concern about a consistent industry implementation. 5) P.S. - Another possible occurrence of a non-zero length field is during Fragmentation. True? Suggestion: Make the control word and its information elements consistent with "draft-ietf-pwe3-protocol-layer-00.txt" across all PWE3 implementations. And provide examples within this umbrella document on it's proper use and best practices. Thanks. :-) -----Original Message----- From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org]On Behalf Of Eric Rosen Sent: Monday, January 06, 2003 1:12 PM To: Shahriar Rahman Cc: pwe3@ietf.org Subject: Re: [PWE3] Padding for ATM cell relay in PW > Perhaps making it explicit that the length field should be non-zero when > (L2 payload + control word length < 64B) && (padding is added) would > clarify it. The problem is that you set the length field when you create the PWE3 packet, and you don't know for sure whether padding will have to be added somewhere down the line. But it's safe to set it to zero if you know that padding will never have to be added. Your observation, I think, is that it is safe to set it to zero if (L2 payload length >= 48 bytes), since two bytes of control word plus a minimum ethernet header would result in a 64 byte ethernet frame, and padding wouldn't be needed. In any event, when decapsulating, you can't assume that padding is present, even if the length field is non-zero, but you don't really care whether padding is present, you only care about the length of the payload. Probably the length field should have been defined as "if the length of the L2 payload is 48 or more bytes, then 0, else the length of the L2 payload". However, the current definition (which is really "if the length of the L2 payload is 62 or more bytes, then 0, else 2 + the length of the L2 payload", I think) does work. I think your real question was: > So, I conclude that there was no padding even though the control word > length field is non-zero. My question is, what should egress LSR do in > this case? Ignore the 'length' value or still apply pad removal procedure > assuming pad is added when 'length' is non-zero? If the length field, is non-zero, it does allow you to correctly deduce the length of the L2 payload, whether padding is present or not, so I don't think this is an issue. Note that what I am saying here is slightly different than what I said in my previous message ;-) Perhaps the length field should be defined as follows: If the L2 payload is 48 bytes or greater, the length field MAY be set to 0; if the L2 payload is 62 bytes or greater, the length field MUST be set to 0; otherwise the length field is set to 2 plus the length of the L2 payload. This preserves interoperability with the Martini docs while allowing the use of 0 in ATM cell mode. _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Shahriar Rahman Subject: RE: Padding for ATM cell relay in PW Date: Mon, 6 Jan 2003 16:17:08 -0800 (PST) Lines: 139 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: erosen@cisco.com, Return-path: To: Peter Reed In-Reply-To: Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Hi Peter, Thanks for digging the detailed on various drafts. I would say that the size of 'length' field in control word is probably none of our concern given that 6 bits all that is needed to rep < 64B. We were trying get to the usage of this field for padding removal/stripping. Regarding the issues you raised, I think the WG is on top of all of them. I can only comment on the last one. I've not seen any reference regarding fragmentation in PW drafts. If you've, please let me know where. regards, Shahriar On Mon, 6 Jan 2003, Peter Reed wrote: > I think a general re-write of the 'Length' field may be in order. In > "draft-ietf-pwe-atm-encap-0.txt", Section 6.5 it states: > > "The one-octet Length indicates length of the packet payload that > includes, length of length field, Sequence number length, the ATM specific > header length and the payload length. ... > > If the PW 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 PW PDU to reach its minimum > size...." > > > > > Issues: > > 1) draft-ietf-pwe-atm-encap-0.txt, Section 6.5 states the Length Field is > one-octet in length not 6 bits, as indicated in > "draft-ietf-pwe3-protocol-layer-00.txt" and other IETF drafts. Page 6 of > "draft-ietf-pwe-atm-encap-0.txt" shows the Length field as 6-bits longs, > which is in conflict with Section 6.5 et al of the same document. > > 2) In the "draft-ietf-pwe-atm-encap-00.txt" on page 6 the un-titled control > word figure shows the Length Field starting in bit position 10 (consistent > with draft-ietf-pwe3-protocol-layer-00.txt), while Figures 2, 3, 4, 5, 6, 10 > indicates a different bit ordering. Is the length field 6 or 8 bits in > length for these modes? What is the ordering (e.g. length/sequence/flag or > sequence/length/flag)? > > 3) Figure 8, draft-ietf-pwe-atm-encap-0.txt, is indeterminate about the > structure of the control word. Given that this section looks very similar to > the Cell Mode description in "draft-martini-l2circuit-encap-mpls-04.txt" my > guess is the length field is 6-bits long and the bit ordering is same as > shown on page 6. But as there are multiple structures of the control word > shown in this document it would be best to spell this out. > > 4) The email thread by authors of the IETF draft conflict with the > information contained within it, which gives me concern about a consistent > industry implementation. > > 5) P.S. - Another possible occurrence of a non-zero length field is during > Fragmentation. True? > > > Suggestion: Make the control word and its information elements consistent > with "draft-ietf-pwe3-protocol-layer-00.txt" across all PWE3 > implementations. And provide examples within this umbrella document on it's > proper use and best practices. > > > > Thanks. :-) > > -----Original Message----- > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org]On Behalf Of Eric > Rosen > Sent: Monday, January 06, 2003 1:12 PM > To: Shahriar Rahman > Cc: pwe3@ietf.org > Subject: Re: [PWE3] Padding for ATM cell relay in PW > > > > > Perhaps making it explicit that the length field should be non-zero when > > (L2 payload + control word length < 64B) && (padding is added) would > > clarify it. > > The problem is that you set the length field when you create the PWE3 > packet, and you don't know for sure whether padding will have to be added > somewhere down the line. But it's safe to set it to zero if you know that > padding will never have to be added. Your observation, I think, is that it > is safe to set it to zero if (L2 payload length >= 48 bytes), since two > bytes of control word plus a minimum ethernet header would result in a 64 > byte ethernet frame, and padding wouldn't be needed. > > In any event, when decapsulating, you can't assume that padding is present, > even if the length field is non-zero, but you don't really care whether > padding is present, you only care about the length of the payload. > > Probably the length field should have been defined as "if the length of the > L2 payload is 48 or more bytes, then 0, else the length of the L2 payload". > However, the current definition (which is really "if the length of the L2 > payload is 62 or more bytes, then 0, else 2 + the length of the L2 payload", > I think) does work. I think your real question was: > > > So, I conclude that there was no padding even though the control word > > length field is non-zero. My question is, what should egress LSR do in > > this case? Ignore the 'length' value or still apply pad removal procedure > > assuming pad is added when 'length' is non-zero? > > If the length field, is non-zero, it does allow you to correctly deduce the > length of the L2 payload, whether padding is present or not, so I don't > think this is an issue. > > Note that what I am saying here is slightly different than what I said in my > previous message ;-) > > Perhaps the length field should be defined as follows: If the L2 payload is > 48 bytes or greater, the length field MAY be set to 0; if the L2 payload is > 62 bytes or greater, the length field MUST be set to 0; otherwise the length > field is set to 2 plus the length of the L2 payload. This preserves > interoperability with the Martini docs while allowing the use of 0 in ATM > cell mode. > > > > > > > > > > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: "Peter Reed" Subject: Length Field def. & Padding for ATM cell relay in PW Date: Tue, 7 Jan 2003 07:21:42 -0800 Lines: 251 Sender: pwe3-admin@ietf.org References: Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: , Return-path: To: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Hi Shahriar: I didn't answer your email well. I don't care if the Length Field is 6 or 8-bits long. What I do care about is consistency in length, bit ordering and use of the fields. It is this consistency that I was arguing for in my previous email posting, plus some best practice examples to assist in uniform implementation. Regards, Peter Reed -----Original Message----- From: Peter Reed [mailto:preed@timetranetworks.com] Sent: Monday, January 06, 2003 4:38 PM To: Shahriar Rahman Subject: RE: [PWE3] Padding for ATM cell relay in PW Hi Shahriar: Totally agree that 6 bits is all that is required. My concern is how the length field is parsed, since the word is 32-bits long and contains other fields. I like fields on nibble/octet boundaries - so if I had a vote I'd say make length 8-bits long, even though the two MSBs will always be zero. But the Martini drafts already set the 6-bit paradigm. In draft-ietf-pwe3-atm-encap-00.txt fragmentation is discussed in the AAL5 modes. Below is a cut and paste from page 29 of that document. The AAL5 transparent VCC service is OPTIONAL. 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Pseudo Wire Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional Length and Sequence Number |M|V|Res|Frg|E|C| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + " | | AAL5 CPCS-PDU | | (n * 48 bytes) | | " | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10: AAL5 transparent service encapsulation The first octet following the Pseudo Wire Header carries control information. The M, V, Res, and C bits are as defined earlier for VCC cell mode. * Frg (Fragmentation) Bits This field is used to support the fragmentation functionality described later in this section. - 11 Single Segment Message (Beginning and End of Message) - 10 Beginning of Message - 00 Continuation of Message - 01 End of Message Cheers, Peter Reed -----Original Message----- From: Shahriar Rahman [mailto:sharahma@cisco.com] Sent: Monday, January 06, 2003 4:17 PM To: Peter Reed Cc: erosen@cisco.com; pwe3@ietf.org Subject: RE: [PWE3] Padding for ATM cell relay in PW Hi Peter, Thanks for digging the detailed on various drafts. I would say that the size of 'length' field in control word is probably none of our concern given that 6 bits all that is needed to rep < 64B. We were trying get to the usage of this field for padding removal/stripping. Regarding the issues you raised, I think the WG is on top of all of them. I can only comment on the last one. I've not seen any reference regarding fragmentation in PW drafts. If you've, please let me know where. regards, Shahriar On Mon, 6 Jan 2003, Peter Reed wrote: > I think a general re-write of the 'Length' field may be in order. In > "draft-ietf-pwe-atm-encap-0.txt", Section 6.5 it states: > > "The one-octet Length indicates length of the packet payload that > includes, length of length field, Sequence number length, the ATM specific > header length and the payload length. ... > > If the PW 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 PW PDU to reach its minimum > size...." > > > > > Issues: > > 1) draft-ietf-pwe-atm-encap-0.txt, Section 6.5 states the Length Field is > one-octet in length not 6 bits, as indicated in > "draft-ietf-pwe3-protocol-layer-00.txt" and other IETF drafts. Page 6 of > "draft-ietf-pwe-atm-encap-0.txt" shows the Length field as 6-bits longs, > which is in conflict with Section 6.5 et al of the same document. > > 2) In the "draft-ietf-pwe-atm-encap-00.txt" on page 6 the un-titled control > word figure shows the Length Field starting in bit position 10 (consistent > with draft-ietf-pwe3-protocol-layer-00.txt), while Figures 2, 3, 4, 5, 6, 10 > indicates a different bit ordering. Is the length field 6 or 8 bits in > length for these modes? What is the ordering (e.g. length/sequence/flag or > sequence/length/flag)? > > 3) Figure 8, draft-ietf-pwe-atm-encap-0.txt, is indeterminate about the > structure of the control word. Given that this section looks very similar to > the Cell Mode description in "draft-martini-l2circuit-encap-mpls-04.txt" my > guess is the length field is 6-bits long and the bit ordering is same as > shown on page 6. But as there are multiple structures of the control word > shown in this document it would be best to spell this out. > > 4) The email thread by authors of the IETF draft conflict with the > information contained within it, which gives me concern about a consistent > industry implementation. > > 5) P.S. - Another possible occurrence of a non-zero length field is during > Fragmentation. True? > > > Suggestion: Make the control word and its information elements consistent > with "draft-ietf-pwe3-protocol-layer-00.txt" across all PWE3 > implementations. And provide examples within this umbrella document on it's > proper use and best practices. > > > > Thanks. :-) > > -----Original Message----- > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org]On Behalf Of Eric > Rosen > Sent: Monday, January 06, 2003 1:12 PM > To: Shahriar Rahman > Cc: pwe3@ietf.org > Subject: Re: [PWE3] Padding for ATM cell relay in PW > > > > > Perhaps making it explicit that the length field should be non-zero when > > (L2 payload + control word length < 64B) && (padding is added) would > > clarify it. > > The problem is that you set the length field when you create the PWE3 > packet, and you don't know for sure whether padding will have to be added > somewhere down the line. But it's safe to set it to zero if you know that > padding will never have to be added. Your observation, I think, is that it > is safe to set it to zero if (L2 payload length >= 48 bytes), since two > bytes of control word plus a minimum ethernet header would result in a 64 > byte ethernet frame, and padding wouldn't be needed. > > In any event, when decapsulating, you can't assume that padding is present, > even if the length field is non-zero, but you don't really care whether > padding is present, you only care about the length of the payload. > > Probably the length field should have been defined as "if the length of the > L2 payload is 48 or more bytes, then 0, else the length of the L2 payload". > However, the current definition (which is really "if the length of the L2 > payload is 62 or more bytes, then 0, else 2 + the length of the L2 payload", > I think) does work. I think your real question was: > > > So, I conclude that there was no padding even though the control word > > length field is non-zero. My question is, what should egress LSR do in > > this case? Ignore the 'length' value or still apply pad removal procedure > > assuming pad is added when 'length' is non-zero? > > If the length field, is non-zero, it does allow you to correctly deduce the > length of the L2 payload, whether padding is present or not, so I don't > think this is an issue. > > Note that what I am saying here is slightly different than what I said in my > previous message ;-) > > Perhaps the length field should be defined as follows: If the L2 payload is > 48 bytes or greater, the length field MAY be set to 0; if the L2 payload is > 62 bytes or greater, the length field MUST be set to 0; otherwise the length > field is set to 2 plus the length of the L2 payload. This preserves > interoperability with the Martini docs while allowing the use of 0 in ATM > cell mode. > > > > > > > > > > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: "Sathappan, Senthilkumar" Subject: FW: proposed change to PW TC MIB Date: Fri, 10 Jan 2003 18:32:14 -0500 Lines: 45 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Return-path: To: "'pwe3@ietf.org'" X-Mailer: Internet Mail Service (5.5.2650.21) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O -----Original Message----- From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] Sent: Friday, January 10, 2003 6:24 PM To: Sathappan, Senthilkumar Cc: 'dave_danenberg@litchfieldcomm.com'; 'davidz@corrigent.com'; 'Andy.Malis@vivacenetworks.com'; Marichetty, Venkatesan Subject: Re: proposed change to PW TC MIB Please re-post to the PWE3 mailing list. (This sounds okay with me.) --Tom >Tom, Dave, David and Andy, > >we are in the process of aligning PW ATM MIB with the new encapsulations >draft (draft-ietf-pwe3-atm-encap-00.txt). > >we think that replacing the atm vc types that are present in PwVcType TC >with the below mentioned types will take care of all the encapsulation modes >presented in the draft. > atmAal5SduVcc > atmAal5PduVcc > atmNto1Transparent > atmCell1to1Vcc > atmCell1to1Vpc > atmCellNto1Vcc > atmCellNto1Vpc > >Please let us know your comments. > >Thanks, >Senthil. "The difficult, we do immediately. The impossible takes a little longer." -- Air Force Motto http://www.mkp.com/books_catalog/catalog.asp?ISBN=1-55860-751-X From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Maarten Vissers Subject: Re: I-D ACTION:draft-riegel-pwe3-tdm-requirements-01.txt Date: Mon, 13 Jan 2003 15:40:01 +0100 Organization: Lucent Technologies Lines: 151 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------C4DDA14BAF4649C73CF82947" Cc: pwe3@ietf.org, gmg1@att.net Return-path: X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (Windows NT 5.0; U) X-Accept-Language: en To: Sasha Vainshtein CC: pwe3@ietf.org, gmg1@att.net Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O This is a multi-part message in MIME format. --------------C4DDA14BAF4649C73CF82947 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sasha, see in-line for some more notes... Sasha Vainshtein wrote: > ... snipped ... > > > The basic PW provides a connection over which a stream of > > bits is transparently > > transported. This is similar to e.g. transporting a stream of > > bits over PDH, > > SDH/SONET or OTN; e.g. 34 Mbit/s over SDH, STM-16 over OTN. > > To guarantee interworking and the performance of a connection, > > jitter/wander, clock and PLL bandwidth specifications have been developed. > See e.g. > > 15.2/G.783 and G.8251. > > > I think that this analogy is correct for unstructured TDM emulation. > Structured TDM > emulation seems to be somewhat different e.g., similar to bit-synchronous > mapping > of 1544 kbit/s into VC-11 and of 2048 kbit/s into VC-12. Is this correct? The difference between async and bit/byte-synchronous mappings is that - in the async mapping case you map the client signal into a server signal which has a clock independent of the client clock. The frequency difference between the client and server signals is coded into justification information and mapped into the server signal as well. - in the bit/byte-sync mapping the server signal's clock is locked to the client signal's clock and there is no justification information needed between client and server signal. The server signal may now have a frequency difference with its server signal (e.g. case of bit/byte-sync mapping of 1544/2048 kbit/s into VC-11/VC-12) and this will be coded into justification info and mapped into the server's server signal. E.g. 2048 async mapping into VC-12 into VC-4 creates 2048 kbit/s justification information (C and S bits) which is mapped into the C-12 with the data bits; as the VC-12 and Vc-4 frequencies are locked (come from same SEC) the TU-12 pointer will have a fixed value and there will be no use of TU-12 pointer adjustment capability. The byte-sync mapping into VC-12 (note bitsync mappings are not deployed in SDH) into VC-4 locks the VC-12 frequency to the 2048 kbit/s frequency (no C+S bits in the mapping as such); the VC-12 now will be independent of the VC-4 frequency and you will see a variable TU-12 pointer value and TU-12 pointer adjustments to cope with the frequency difference between the 2048 kbit/s signal and the SEC signal (creating the VC-4 signal). If you map a number of consecutive bits from a client signal into a PW packet without any justification control added in the mapping process, then the mapping looks like a bitsync, bytesync or framesync mapping. The justification control is then implicit in the time of packet generation. With additional delay variation in the network, its will be hard to recover client signal timing at the egress of the PW. If you include justification control in the packet itself, you will have a mapping that looks like an async mapping. The additional complexity compared to async mappings in PDH, sDH, OTN is the delay each packet can get crossing the network, which results in a much larger jitter/wander component than traditionally present when using PDH, SDH or OTN as carrier for the mapped signal. I would not relate structured TDM emulation with a particular mapping type. E.g. take the example of a DS3 with DS1s inside and DS1 PWs. The ingress of the PSN terminates the DS3 and extracts the DS1 signals. Those DS1s are now mapped into PWs and PWs are multiplexed. I.e. this is much like async or bitsync mapping of individual DS1 signals into PWs. For SDH structured TDM signals (VC-12 into VC-4 into STM-N) the case is similar. However, as VC-12 and VC-4 signals have been transported so far only within (synchronous) STM-N, sSTM-2n/1k and G.832 34/140 Mbit/s frames there are no VC-n jitter/wander, clock and PLL specifications written. And with the pointer buffers around, such specifications would have a different format than for the PDH signals. A VC-n signal coming out of a PW enters a pointer buffer with a pointer generator; the pointer generator must generate pointer sequences compliant to those specified in clause 15/G.783. Delay variation can be accommodated to a certain level. The best person (in my opinion) to look into the jitter/wander requirements of this PW is Geoff Garner. For structured 1544/2048 kbit/s signals with 64 kbit/s (DS0) trib signals the same is true. DS0 trib signals can be mapped async in a MPLS PW packet, or bit/byte sync. If you would like to map DS0's from multiple 1544/2048 kbit/s input signals into one MPSL PW packet, then you have to perform DS0 multiplexing before mapping. Delay variations through the network result in slip/skip when the 64 kbit/s signals are mapped into another 1544/2048 kbit/s signal. Jitter/wander spec's can be written as well for this case, based on a defined buffer size. In general transport of a CBR stream via an MPLS network can be based on a common mapping method. This method is independent on the ingress/egress signals carrying the to be transported client signal. In functional modelling you will notice that the atomic functions that have to deal with demuxing before the PW and muxing after the PW already exist and thus don't belong to the PW operation itself. The PW should be concerned with mapping and demapping of the client's characteristic information only, not with the presentation of this CI on a physical interface at the edge of the network. As such, PW should address mapping/demapping of the following CI - P12x_CI (E1 unstructured) - P11x_CI (T1 unstructured) - P31x_CI (E3 unstructured) - P32x_CI (T3 unstructured) - P0x_CI (DS0 unstructured) - P0s_CI (DS0 with byte identification) Note - CAS is a particular implementation of a signalling channel. Besides CAS we have e.g. TR303 and V5.1/V5.2 implementations. - P0s-Xc_CI (NxDS0) - S3_CI (STS-1/VC-3) - S4/4-4c/4-16c/4-64c_CI - S11/12_CI (VT-3, VT-6/VC-2 are not deployed in the network) - S11/12/3/4-Xv_CI (virtual concatenation) If you use these client signal indications, you don't have to bother about all the PDH or SDH/SONET processing between the physical interface connector and the PW; all components can be found in ITU-T recommendations. It is a manufacturer and/or operator responsibility to define which variations will be offered/is required between connector and PW edge. Regards, Maarten --------------C4DDA14BAF4649C73CF82947 Content-Type: text/x-vcard; charset=us-ascii; name="mvissers.vcf" Content-Description: Card for Maarten Vissers Content-Disposition: attachment; filename="mvissers.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Vissers;Maarten tel;cell:+31 62 061 3945 tel;home:+31 35 526 5463 tel;work:+31 35 687 4270 x-mozilla-html:FALSE org:Lucent Technologies;NA&CPSE adr:;;Larenseweg 50;Hilversum;;1221 XL;Netherlands version:2.1 email;internet:mvissers@lucent.com title:Consulting Member of Technical Staff fn:Maarten Vissers end:vcard --------------C4DDA14BAF4649C73CF82947-- From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: "Dave Danenberg" Subject: RE: FW: proposed change to PW TC MIB Date: Mon, 13 Jan 2003 10:53:38 -0500 Lines: 63 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Return-path: X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] FW: proposed change to PW TC MIB Thread-Index: AcK5AOwDsOV/Nwb6TISBkJDHWu3G0QCGuBbw To: "Sathappan, Senthilkumar" , X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0DG4UJ01632 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Fine with me as well. > -----Original Message----- > From: Sathappan, Senthilkumar > [mailto:senthilkumar.sathappan@marconi.com] > Sent: Friday, January 10, 2003 6:32 PM > To: 'pwe3@ietf.org' > Subject: [PWE3] FW: proposed change to PW TC MIB > > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: Friday, January 10, 2003 6:24 PM > To: Sathappan, Senthilkumar > Cc: 'dave_danenberg@litchfieldcomm.com'; 'davidz@corrigent.com'; > 'Andy.Malis@vivacenetworks.com'; Marichetty, Venkatesan > Subject: Re: proposed change to PW TC MIB > > Please re-post to the PWE3 mailing list. > > (This sounds okay with me.) > > --Tom > > > > >Tom, Dave, David and Andy, > > > >we are in the process of aligning PW ATM MIB with the new > encapsulations > >draft (draft-ietf-pwe3-atm-encap-00.txt). > > > >we think that replacing the atm vc types that are present in > PwVcType TC > >with the below mentioned types will take care of all the > encapsulation > modes > >presented in the draft. > > atmAal5SduVcc > > atmAal5PduVcc > > atmNto1Transparent > > atmCell1to1Vcc > > atmCell1to1Vpc > > atmCellNto1Vcc > > atmCellNto1Vpc > > > >Please let us know your comments. > > > >Thanks, > >Senthil. > > "The difficult, we do immediately. The impossible takes a > little longer." > -- Air Force Motto > > http://www.mkp.com/books_catalog/catalog.asp?ISBN=1-55860-751-X > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-l2tpext-l2tp-base-05.txt Date: Tue, 14 Jan 2003 10:13:55 -0500 Lines: 81 Sender: pwe3-admin@ietf.org Reply-To: Internet-Drafts@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: l2tpext@ietf.org, pwe3@ietf.org Return-path: To: IETF-Announce: ; Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , X-Spam-Report: 5 hits, 5 required; * 1.1 -- To: has a malformed address * 0.5 -- From: does not include a real name * 2.2 -- BODY: Claims you can be removed from the list * 1.1 -- BODY: A word in all caps repeated on the line * 0.1 -- RAW: MIME filename does not match content Status: O --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Layer Two Tunneling Protocol Extensions Working Group of the IETF. Title : Layer Two Tunneling Protocol (Version 3)'L2TPv3' Author(s) : J. Laurence, W. Townsley, I. Goyret Filename : draft-ietf-l2tpext-l2tp-base-05.txt Pages : 80 Date : 2003-1-13 This document describes 'version 3' of the Layer Two Tunneling Protocol (L2TPv3). L2TPv3 defines the extensions to RFC2661 (L2TPv2) necessary to provide a basis for tunneling a variety of layer 2 data link types across a packet switched network (such as an IP network). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2tpext-l2tp-base-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-l2tpext-l2tp-base-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-l2tpext-l2tp-base-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Danny McPherson Subject: WG LC on PWE3 Requirements Ended Date: Tue, 14 Jan 2003 08:32:21 -0700 Lines: 28 Sender: pwe3-admin@ietf.org Reply-To: danny@tcb.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: pwe3@ietf.org Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Folks, this last call has ended. ------- Forwarded Message From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Danny McPherson Subject: IETF 56 PWE3 Slot Request Date: Tue, 14 Jan 2003 08:43:09 -0700 Lines: 15 Sender: pwe3-admin@ietf.org Reply-To: danny@tcb.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: pwe3@ietf.org Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O If you'd like a few minutes to talk during the upcoming meeting please send me a request with the following information: 1. How much time you need and the discussion "title". 2. One to two sentences on EXACTLY what you plan to discuss. Note that if you've not discussed it on the mailing list already don't bother requesting a slot. 3. Filename of any document you're planning to discuss with publicly accessible pointer (preferably being the Internet- Drafts directory on the IETF servers). -danny From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Danny McPherson Subject: IETF 56 Cut-off dates Date: Tue, 14 Jan 2003 08:54:41 -0700 Lines: 15 Sender: pwe3-admin@ietf.org Reply-To: danny@tcb.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: pwe3@ietf.org Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Folks, here are the "important dates" for the upcoming meeting. Pay special attention to the draft submission cut-off dates: 56th IETF Meeting - San Francisco, CA, USA Important Meeting Dates January 7, Tuesday - Working Group and BOF scheduling begins January 13, Monday - Registration begins February 24, Monday - Internet Draft Cut-off for initial document (-00) submission at 09:00 ET February 25, Tuesday - Working Group and BOF scheduling closes at 17:00 ET March 3, Monday - Internet Draft final submission cut-off at 09:00 ET March 7, Friday - Registration and Pre-payment cut-off at 12:00 noon ET March 12, Wednesday - Registration cancellation From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Danny McPherson Subject: Draft Progress [Authors READ!] Date: Tue, 14 Jan 2003 08:52:41 -0700 Lines: 25 Sender: pwe3-admin@ietf.org Reply-To: danny@tcb.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: pwe3@ietf.org Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Folks, We were slated to Last Call several documents before the IETF 56 meeting. However, there's been little work on some of the documents or no updates submitted since the last meeting. I'm planning to update the WG Goals & Milestones and need the authors/editors of WG documents to let me know when they'll have something ready for WG last call. As such, regardless of what you believe the current state of your PWE3 draft to be, please send me a note with the current status (i.e., where you are with editing) of the document and the projected timeline for submission of the next update. On a related note, as an FYI, it has been agreed that draft-rosen-mpls-in-ip-or-gre-00.txt will become an MPLS WG document and MPLS PWs will be removed from the PWE3 charter. Although unlikely(?), if anyone has a particular issue with this please send me a note. -danny From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Stewart Bryant Subject: PWE3 congestion Date: Thu, 16 Jan 2003 18:54:12 +0000 Organization: Cisco Systems, Inc. Lines: 31 Sender: pwe3-admin@ietf.org Reply-To: stbryant@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en To: "pwe3@ietf.org" Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O I am looking at the congestion section of the arch revision (we need one). It seems to me that we can divide the problem up into two traffic classes: o Traffic known (perhaps by SLA, perhaps by audit) to be TCP friendly o Traffic of unknown provenance In the former case we need do nothing. Natural packet discard will feed back to the transport layer, and the right things will happen. I include in this case IP over packet PW, and IP over ATM PW. I propose that the term "TCP friendly" be left sufficiently general that it covers any IETF transport (they are all supposed to be TCP friendly), and other similar transports such as TP4 (if it still exists). For the "traffic of unknown provenance", it seems to me that could be used to calculate the maximum offered load, and the PE would then be required to maintain it's load below this rate (if necessary by shutting down PWs). The statistics needed to operate this algorithm look a bit daunting for a forwarding system, but presumably some stastical view of the counters, a priori knowledge of the bit rate etc would simplify things. Has anyone elso looked at this, and does it seem like the right way to go? Stewart From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Max Riegel Subject: Re: Comments/ questions to draft-riegel-pwe3-tdm-requirements-01.txt Date: Mon, 20 Jan 2003 16:32:28 +0100 Lines: 146 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: pwe3@ietf.org Return-path: X-Sender: rm049557@139.21.212.200 X-Mailer: QUALCOMM Windows Eudora Version 5.1 To: Alik Shimelmits In-Reply-To: Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Dear Alik, sorry for the late response. I missed your mail when browsing through the PWE3 list on Christmas but discovered it now when cleaning up my inbox. At 23.12.2002 10:02 +0100, Alik Shimelmits wrote: Max and all, Please, find below some comments and questions. May be some of them are rather trivial but I think it would be better to deal with them EXPLICITLY. SECTION 5.2 Q1. What is the difference between structured E1, T1 and nx DS0 as it mentioned in 5.2? In the former case a whole E1 or T1 frame is transmitted in a aligned fashion, in the latter just a set of DS0 channels eventually associated with CAS signals are transmitted. - about n x DS0: Q2. Is there requirement for DS0s in the bundle to be consecutive or not? What do you mean with DS0s to be consecutive? Q3. Whether PW should support DS0s "cross-connect" over PSN,i.e. whether DSOs at both sides of PW may be different, e.g. [1,2,3] at the local side and [7,8,9] at the remote one? Putting individual DS0 channels into a higher order TDM framing can be considered as part of the NSP (Native Service Processing) being outside the scope of the PW emulation for nx DS0s. Q4. How many nxDS0 PW end-points may be defined on a single T1 or E1 interface? Actually, whether distributed DS0 cross-connect over PSN may be implemented using nxDS0 emulated PWs? This seems for me also being an issue of the NSP outside the scope of emulation of PW for nxDS0. Q5. Is it possible to connect n x DS0 bundle residing on T1 with the n x DS0 residing on E1? It should be possible if you are applying appropriate NSP functions. - n x DS0 versus n x DS0 with CAS I see a problem here. I think n x DS0 must maintain frame integrity, i.e. all DS0s within the bundle should be played out exactly with the same delay. Frame integrity is the MUST requirement when you carry bundle of DS0s as a whole (and that happens when you provide just transparent pipe and not aware about type of running traffic, e.g. data). To some extent this approach is similar to the notion of concatenated containers in SDH / SONET. This is the major difference between n x DS0 and n x DS0 with CAS! When we consider n x DS0 with CAS we can safely state that we deal with voice channels. I wouldn't draw such a conclusion. You never cant be sure what is transported in a DS0 channel, even might be somebody is using data-over-voice. Each voice channel should be synchronized with its own signalling but there is no requirement for synchronization between channels! And this is extremely important. Probably this is the case for applying structured E1 / T1 emulation. Actually, n x DS0 with CAS deals with independent voice channels that are packed into common packets for bandwidth effeciency only. So, the next step to improve bandwidth efficiency in this application we usually activate idle suppression (i.e. not transmit the specific DS0 when it is in "on-hook") and then VAD (voice activity detection). And so on.. I.e. we operate per DS0. BTW, that also allows introduction of more gentle congestion control that may operate at the DS0 level, especially when "coming back". I assume that this fundamental difference in the requirements that can or cannot to lead to different solutions but I'd propose at least to include that into requirements document and not to consider these two different applications under the same application space. SECTION 5.3 Q1. reference on VC-13 in section 5.3 - is it just a mistyping? most of the questions below are similar to the questions on the n x DS0 section (above). That is not surprising for me because intuitively both n x DS0 and n x VC-x look similar (sub-structures of a single server structure). It's a typo. Please have a look on Ron's posting on 2002-12-22. Q2. what n x VC12/11/2 specifies - concatenated transport or just logical bundling? Requirements for concatenated are different from simple grouping. Q3. low order VC-x is always part either of high order VC-3 or VC-4. Whether the nx VC-x PW should support VC-x "cross- connect" over PSN,i.e. whether VC-x at both sides of PW may be different, e.g. [111,112,113] (using KLM notation) at the local side and [121,122,123] at the remote one? Q4. Can a n x VC12 PW connect a group of VC12 under high order VC-3 to a group of VC12 under high order VC-4? SECTION 7.3.1 I believe there are two different scenarios - occasional and persistent loss of packets. It looks that the requirements for handling are also different. E.g. for n x DS0 with CAS - handling of persistent loss of packets should also include generation of associated signalling, that may require to define "default" CAS bits that should be transmitted towards TDM line in case of packet loss. In this case PW end point is aware about specific protocol used by the provider :) Handling of the occasional packet loss may be simply re- play of the last CAS state. There was a presentation of Yaakov in Atlanta, how to deal with transmission errors, and there was a conclusion to put the related information in a BCP (best current practicies) document, as it is not part of the PWE3 specification but seemed to be very useful for equipment designers. GENERAL -The document specifies (section 2) the need to put special emphasis on minimization of one-way delay. End-2-end delay (that actually is the sum of packetiztion delay, network delay and delay introduced by the jitter buffer] is important paramater for network designer. I would propose to include the requirement for n x DS0 and n x VC-x services - end-2-end delay should be not depend upon the value of n. -I am afraid that there might be an overlap between n x DS0 with CAS and AVT WG activities: RFC 2833 defines how to carry telephony signals over the network, and, at least, in the past(!) a lot of work about multiplexing/bundling of voice streams was done in AVT WG (e.g. draft-ietf-avt-aggregation-00.txt - expired in 1998). What do you think? Keeping end2end delay constant in case of transmission of voice signals looks reasonable for me. But taking into account that we are only dealing with a part of the end2end transmission path (the pseudo wire emulation edge2edge) I wouldn't put any requirements for the end2end behaviour into our document. Bye Max From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: David Clear Subject: Questions from draft-ietf-pwe3-control-protocol-01.txt Date: Wed, 22 Jan 2003 15:28:04 -0800 Lines: 83 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2C26D.E97C5AA0" Return-path: To: "'pwe3@ietf.org'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2C26D.E97C5AA0 Content-Type: text/plain; charset="iso-8859-1" Hi. A few questions I hope you can help with. [Frame Relay PW over MPLS] 1. Section 4.1 references draft-ietf-pwe3-frame-encap-01.txt, but I can't seem to find that draft (nor an -00 version). Has it been superceded by draft-ietf-pwe3-frame-relay-00.txt? 2. If LDP is used to signal a PW type of 0x0001 (Frame Relay DLCI), does that correspond to the "one-to-one" mode or "port mode" encapsulation (from draft-ietf-pwe3-frame-relay-00.txt (if that's the current one))? [ATM PW over MPLS] 3. Do LDP PW types 0x9 (ATM VCC cell transport) and 0xa (ATM VPC cell transport) refer to "one-to-one" mode or "n-to-one" mode encaps (from draft-ietf-pwe3-atm-encap-00.txt)? Section 4.2.3 reads: "Every cell that is received... is encapsulated according to [10], ATM cell mode...", but "ATM cell mode" does not zero in on a specific section from atm-encap draft. I figure it's n-to-one, but I would like confirmation. Regards, David. ------_=_NextPart_001_01C2C26D.E97C5AA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Questions from draft-ietf-pwe3-control-protocol-01.txt

Hi.  A few questions I hope you = can help with.

[Frame Relay PW over MPLS]
1. Section 4.1 references = draft-ietf-pwe3-frame-encap-01.txt, but I can't seem to find that draft = (nor an -00 version).  Has it been superceded by = draft-ietf-pwe3-frame-relay-00.txt?

2. If LDP is used to signal a PW type = of 0x0001 (Frame Relay DLCI), does that correspond to the = "one-to-one" mode or "port mode" encapsulation = (from draft-ietf-pwe3-frame-relay-00.txt (if that's the current = one))?

[ATM PW over MPLS]
3. Do LDP PW types 0x9 (ATM VCC cell = transport) and 0xa (ATM VPC cell transport) refer to = "one-to-one" mode or "n-to-one" mode encaps (from = draft-ietf-pwe3-atm-encap-00.txt)?  Section 4.2.3 reads: = "Every cell that is received... is encapsulated according to [10], = ATM cell mode...", but "ATM cell mode" does not zero in = on a specific section from atm-encap draft.  I figure it's = n-to-one, but I would like confirmation.


Regards,
David.

------_=_NextPart_001_01C2C26D.E97C5AA0-- From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Danny McPherson Subject: Internet-Draft Cutoff Dates for San Francisco, CA (March 16-21,2003) (fwd) Date: Fri, 31 Jan 2003 08:15:04 -0700 Lines: 50 Sender: pwe3-admin@ietf.org Reply-To: danny@tcb.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: pwe3@ietf.org Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O FYI... ------- Forwarded Message From owner-ietf-announce@ietf.org Wed Dec 27 16:41:43 2006 To: IETF-Announce: ; From: Internet-Drafts Administrator Subject: Internet-Draft Cutoff Dates for San Francisco, CA (March 16-21,2003) Date: Fri, 31 Jan 2003 09:51:02 -0500 Sender: owner-ietf-announce@ietf.org Precedence: bulk Status: O NOTE: There are two(2) Internet-Draft Cutoff dates February 24th: Cutoff for Initial Submissions (new documents). All initial submissions (00.txt) must be submitted by Monday, February 24th, at 09:00 ET. Initial submissions receieved after this time will NOT be made available in the Internet-Drafts directory, and will have to be resubmitted. As before, all initial submissions (00.txt) with a filename beginning with a draft-ietf MUST be approved by the appropriate WG Chair prioir to processing and announcing. WG Chair approval must be received by Monday, February 24th. Please do NOT wait until the last minute to submit. Be advised: NO placeholders. Updates to initial submission received the week of February 24th will NOT be accepted. March 3rd: FINAL Internet-Draft Cutoff All revised Internet-Draft submissions must be submitted by Monday, March 3rd, 2003 at 09:00 ET. Internet-Drafts received after this time will NOT be announced NOR made available in the Internet-Drafts Directories. We will begin accepting Internet-Draft submissions the week of the meeting, though announcements will NOT be sent until the IETF Meeting is over. Thank you for your understanding and cooperation. Please do not hesitate to contact us if you have any questions or concerns. FYI: These and other significant dates can be found at http://www.ietf.org/meetings/cutoff_dates_56.html ------- End of Forwarded Message From pwe3-admin@ietf.org Wed Dec 27 16:41:43 2006 From: Shahram Davari Subject: RE: Re: Comments/ questions to draft-riegel-pwe3-tdm-requi rements-01.txt Date: Fri, 31 Jan 2003 07:18:54 -0800 Lines: 47 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: pwe3@ietf.org Return-path: To: "'Max Riegel'" , Alik Shimelmits X-Mailer: Internet Mail Service (5.5.2656.59) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > > GENERAL -The document specifies (section 2) the need to put special > emphasis on minimization of one-way delay. End-2-end delay (that > actually is the sum of packetiztion delay, network delay and delay > introduced by the jitter buffer] is important paramater for network > designer. I would propose to include the requirement for n x DS0 and n > x VC-x services - end-2-end delay should be not depend upon the value > of n. I don't think such a requirement is needed. Not only such requirement makes the design of the PW box more complicated, but also due to variable overhead it makes the capacity planning next to impossible. Also a few msec differences won't be noticeable by the end user. Remember we are not trying to perfectly emulate TDM networks. IP networks have characteristics that needs to be considered. -Shahram -I am afraid that there might be an overlap between n x DS0 with > CAS and AVT WG activities: RFC 2833 defines how to carry telephony > signals over the network, and, at least, in the past(!) a lot of work > about multiplexing/bundling of voice streams was done in AVT WG (e.g. > draft-ietf-avt-aggregation-00.txt - expired in 1998). What do you > think? > > Keeping end2end delay constant in case of transmission of > voice signals > looks reasonable for me. But taking into account that we are > only dealing > with a part of the end2end transmission path (the pseudo wire > emulation > edge2edge) I wouldn't put any requirements for the end2end > behaviour into > our document. > > Bye > Max > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 >