idnits 2.17.1 draft-davari-mpls-diff-ppp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 9) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 10 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 76 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([ECN]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 1999) is 8960 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'DIFF-EF' is defined on line 493, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2481 (ref. 'ECN') (Obsoleted by RFC 3168) Summary: 9 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Shahram Davari 2 INTERNET DRAFT PMC-Sierra Inc. 3 Expires October 1999 4 Ram Krishnan 5 Nexabit Networks 7 Pasi Vaananen 8 Nokia 10 April, 1999 12 MPLS Support of Differentiated Services over PPP links 14 16 Status of this Memo 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet- Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Abstract 39 This document proposes a technique for MPLS to support Differentiated 40 Services (Diff-Serv) over PPP links in non-ECN-capable [ECN] networks. 42 Briefly, we propose that: 44 - Packets belonging to the same PHB forwarding class (PFC), as defined 45 in [DIFF_MPLS_EXT], be transported over the same PPP LSP. 47 - For a given FEC, a separate PPP LSP should be established for each 48 PFC, so that multiple PPP LSPs are established in parallel for 49 support of Diff-Serv. 51 - Among a set of PHBs transported over the same PPP LSP, the different 52 PHBs' drop Precedence (DP) be mapped into the EXP field (3 bits) of 53 the MPLS shim header (note that DP is implicitly a part of DSCP). 55 The required updates to the current MPLS LDP and MPLS RSVP messages 56 (for LSP establishment in order to support Diff-Serv over PPP LSRs) 57 are the same as the ones proposed in [MPLS_DIFF_EXT]. 59 1. Introduction 61 In an MPLS domain [MPLS_ARCH], when a stream of data traverses a 62 common path, a Label Switched Path (LSP) can be established using 63 MPLS signaling protocols. At the ingress Label Switch Router (LSR), 64 each packet is assigned a label and is transmitted downstream. At 65 each LSR along the LSP, the label is used to forward the packet to 66 the next hop. 68 In a Differentiated Service (Diff-Serv) domain [DIFF_ARCH] all the IP 69 packets crossing a link and requiring the same Diff-Serv behavior are 70 said to constitute a Behavior Aggregate. At the ingress node the 71 packets are classified and marked with a Diff-Serv Code Point (DSCP) 72 which corresponds to their Behavior Aggregate. At each transit node, 73 the DSCP is used to select the Per Hop Behavior (PHB) that determines 74 the queuing treatment and, in some cases, drop probability for each 75 packet. 77 This document proposes a solution for supporting the currently 78 defined Diff-Serv PHBs over a non-ECN-capable PPP MPLS network, i.e., 79 an MPLS network implemented using non-ECN-capable PPP routers. 81 1.1. PHB Forwarding Class 83 [MPLS_DIFF_EXT] defines a set of PHBs that require no misordering of 84 packets in a microflow (even if the microflow contains packets for 85 more than one PHB) as a PHB Forwarding Class (PFC). The mechanisms 86 described in this draft aim to preserve the correct ordering 87 relationships for packets that belong to a single PFC. 89 1.2. LSP Establishment in Diff-Serv over PPP MPLS 91 Recognizing that: 93 - MPLS over PPP links requires the use of a Shim Header, which consists 94 of a label stack with one or more entries [MPLS_ENCAPS]; 96 - The Diff-Serv Code Point (DSCP) is 6-bit long [DIFF_HEADER], which 97 can not be copied entirely in to the 3-bit long EXP field of the MPLS 98 shim header; 100 We propose that: 102 - All packets belonging to a single PFC and the same Forwarding 103 Equivalent Class (FEC) should be sent down a single LSP; 105 - One LSP should be established per pair (rather than 106 simply one LSP per FEC as in a network that does not support 107 Diff-Serv); 109 - Multiple PHBs belonging to the same PFC be granted different Drop 110 Precedence (DP) values through appropriate coding of the EXP field 111 of the top label entry of the shim header. 113 MPLS specifies how LSPs can be established via multiple signaling 114 protocols. This Internet-Draft assumes the extensions to LDP and 115 RSVP are those defined in [MPLS_DIFF_EXT], which allow establishment 116 of one LSP per pair over a PPP link. 118 1.3. Label Forwarding for Support of Diff-Serv over PPP MPLS 120 Label forwarding for support of Diff-Serv over PPP MPLS domain can be 121 broken down into three regions: 123 - Ingress node 124 - Egress node 125 - Interior node 127 On the other hand the Ingress and Egress links may be one of the 128 followings: 130 - Non-MPLS link 131 - MPLS link of the same hierarchical level 132 - MPLS link of different hierarchical level 134 Let us further assume that the upstream and downstream links of an 135 Interior node are in the same hierarchical level. 137 1.3.1 Ingress Node Label Forwarding 139 At the Ingress edge of a PPP Diff-Serv MPLS cloud, the Edge-LSR should 140 identify the PHB of an incoming packet (note that PHB consists of PFC 141 and DP). It should then determine the outgoing PHB according to some 142 local policy and/or traffic conditioning function and map it to the 143 outgoing packet. 145 The following actions are taken by the Ingress-LSR depending on the 146 Ingress link type and hierarchical level: 148 - If the incoming packet is coming through a non-MPLS PPP/ATM/FR link 149 (unlabeled packet), the Edge-LSR determines the incoming packet's PHB 150 by looking at its IP DSCP, according to the mappings defined in 151 [DIFF_HEADER], [DIFF_AF], [DIFF_EF]. It then determines the packet's 152 outgoing PHB according to some local policy and/or traffic conditioning. 153 Based on the FEC and PFC of the outgoing packet, the Edge-LSR selects 154 the LSP among the set of LSPs established for each pair. The 155 PPP Edge-LSR then inserts a shim header and sets the EXP field of the 156 top label entry according to the mapping defined below between the 157 outgoing PHBs and the EXP field + PFCs (section 2.1). 159 - If the incoming packet is coming through an MPLS PPP link (labeled 160 packet), which is in the same hierarchical level as the downstream 161 link, then the Ingress LSR should act like an Interior LSR described in 162 section 1.3.3. 164 - If the incoming packet is coming through an MPLS PPP link (labeled 165 packet), and this is the start of a hierarchical tunnel, the Ingress 166 Edge-LSR first determines the packet's PFC from the incoming LSP among 167 the set of LSPs established for the pair. It then determines 168 the incoming packet's PHB from this PFC and from the EXP field of the 169 top label entry of the label stack according to the mapping defined 170 below between the EXP fields + PFCs and the PHBs (section 2.2). It then 171 deteremines the PHBs for the two levels of hierarchy according to some 172 local policy and/or traffic conditioning. At each level, based on the 173 FEC and PFC of the outgoing packet, the Edge-LSR selects the LSP among 174 the set of LSPs established for each . It then pushes a new 175 label entry into the label stack and sets the EXP field of the new 176 label entry and the lower label entry (i.e., the incoming label entry) 177 according to the mapping defined below between PHBs and the EXP field 178 + PFCs (section 2.1). Note that these two labels may have similar or 179 different EXP fields. 181 - If the incoming packet is coming through an MPLS ATM/FR link (labeled 182 packet), which is in the same hierarchical level as the downstream link, 183 the Ingress first determines the packet's PFC from the incoming LSP 184 among the set of LSPs established for the pair. It then 185 determines the incoming packet's PHB from this PFC and from the CLP/DE 186 bit and/or EXP field of the top label entry of the label stack 187 according to a mapping between CLP/DE bit and/or EXP field and the PHBs 188 , which is outside the scope of this document and is yet to be defined. 189 It then determines the packet's outgoing PHB according to some local 190 policy and/or traffic conditioning. Based on the FEC and PFC of the 191 outgoing packet, the Edge-LSR selects the LSP among the set of LSPs 192 established for each . It then sets the EXP field of the top 193 label entry, according to the mapping defined below between the outgoing 194 PHB and EXP field + PFCs (section 2.1). 196 - If the incoming packet is coming through an MPLS ATM/FR link (labeled 197 packet) and this is the start of a hierarchical tunnel, the Ingress 198 Edge-LSR first determines the incoming packet's PFC from the incoming 199 LSP among the set of LSPs established for the pair. It then 200 determines the incoming packet's PHB from this PFC and from the CLP/DE 201 bit and/or EXP field of the top label entry of the label stack 202 according to a mapping between CLP/DE bit and/or EXP field and the PHBs 203 , which is outside the scope of this document and is yet to be defined. 204 It then determines the PHBs for the two levels of hierarchy according 205 to some local policy and/or traffic conditioning. At each level, based 206 on the FEC and PFC of the outgoing packet, the Edge-LSR selects the LSP 207 among the set of LSPs established for each . It then pushes a 208 new label entry into the label stack and sets the EXP field of the new 209 label entry and the lower label entry (i.e., the ATM/FR label entry) 210 according to the mapping defined below between PHBs and the EXP field 211 + PFCs (section 2.1). Note that these two labels may have similar or 212 different EXP fields. 214 1.3.2 Egress Node Label Forwarding 216 At the Egress edge of a PPP Diff-Serv MPLS cloud, the Edge-LSR first 217 determines the packet's PFC from the incoming LSP among the set of LSPs 218 established for the pair. It then determines the incoming 219 packet's PHB from this PFC and from the EXP field of the top label 220 entry of the label stack according to the mapping defined below between 221 the EXP fields + PFCs and the PHBs (section 2.2). It then determines 222 the packet's outgoing PHB according to some local policy and/or traffic 223 conditioning and maps that into the outgoing packet depending on egress 224 link type and hierarchical level as explaind below: 226 - If the outgoing link is a non-MPLS PPP/ATM/FR link (unlabeled packet) 227 , the Edge-LSR pops the shim header and sets the IP DSCP of the packet 228 based on the outgoing PHBs according to the mappings defined in 229 [DIFF_HEADER], [DIFF_AF], [DIFF_EF]. 231 - If the outgoing packet is labeled and is going through a PPP egress 232 link, which is in the same hierarchical level as the upstream link, 233 then the Egress LSR should act as an Interior LSR described in section 234 1.3.3. 236 - If the outgoing packet is going through an MPLS PPP link (labeled 237 packet) and this is the end of a hierarchical tunnel, based on the FEC 238 and PFC of the outgoing packet, the Edge-LSR selects the LSP among the 239 set of LSPs established for each . It then pops the top label 240 entry and sets the EXP field of the lower label entry according the 241 mapping defined below between PHBs and EXP field + PFCs (section 2.1). 243 - If the outgoing packet is going through an MPLS ATM/FR link (labeled 244 packet), which is in the same hierarchical level as the upstream link, 245 based on the FEC and PFC of the outgoing packet, the Edge-LSR selects 246 the LSP among the set of LSPs established for each . It then 247 sets the EXP field of the shim header's top label entry (i.e., ATM/FR 248 label entry) according to the mapping defined below between PHBs and the 249 EXP field + PFCs (section 2.1). It also sets the CLP/DE bit according to 250 the mapping defined in [MPLS_DIFF_EXP] between PHBs and CLP/DE bit. 252 - If the outgoing packet is going through an MPLS ATM/FR link (labeled 253 packet) and this is the end of a hierarchical tunnel, based on the FEC 254 and PFC of the outgoing packet, the Edge-LSR selects the LSP among the 255 set of LSPs established for each . It then pops the top label 256 entry and sets the EXP field of the lower label entry according to the 257 mapping defined below between PHBs and EXP field + PFCs (section 2.1). 259 It also sets the CLP/DE bit according to the mapping defined in 260 [MPLS_DIFF_EXP] between PHBs and CLP/DE bit. 262 1.3.3 Interior Node Label Forwarding 264 At the Interior of a PPP Diff-Serv MPLS cloud, the Interior-LSR, which 265 receives and transmits labeled packet on PPP links, which are at the 266 same heirarchical level, will perform the following action: 268 - The Interior LSR first determines the packet's PFC from the incoming 269 LSP among the set of LSPs established for the pair. It then 270 determines the incoming packet's PHB from this PFC and from the EXP 271 field of the top label entry of the label stack according to the mapping 272 defined below between the EXP fields + PFCs and the PHBs (section 2.2). 273 It then determines the packet's outgoing PHB according to some local 274 policy and/or traffic conditioning. Based on the FEC and PFC of the 275 outgoing packet, the Interior LSR selects the LSP among the set of LSPs 276 established for each . The Interior LSR then sets the EXP 277 field of the top label entry of the stack according to the mapping 278 defined below between the PHBs and the EXP field + PFcs (section 2.1). 280 2. PHB Mapping into PFCs and Selective Discard Mechanism 282 The mapping from the AF and EF PHBs into the PFCs are the same as 283 those defined in [MPLS_DIFF_EXT]. While the mapping from PHBs into the 284 EXP field + PFCs and the mapping from EXP field + PFCs into the PHBs are 285 described below. 287 2.1 Mapping PHBs into the EXP Field and PFCs 289 This section covers the mapping from AF and EF PHBs into the EXP field 290 of the Shim Header and the PFC. 292 There are 4 PFCs defined for AF PHBs and within each AF PFC there are 293 3 drop precedences, which get mapped into the EXP field. There is only 294 one PFC with one drop precedence defined for the EF PHB and the DF PHB 295 (Default Forwarding), which gets mapped into the EXP field. 297 The mapping from AF, EF and DF PHBs into the EXP field of the shim 298 header and the PFCs is as follows: 300 PHB EXP Field PFC 302 AFx1 -----> 000 AFCx 303 AFx2 -----> 001 AFCx 304 AFx3 -----> 010 AFCx 305 EF -----> 000 EFC 306 DF -----> 000 DFC 308 The AFCx and EFC per-hop forwarding classes (PFC) are defined in 309 [MPLS_DIFF_EXT]. The DFC (Default Forwarding Class) corresponds to the 310 PHB-group Forwarding Class for the DF PHB. 312 2.2 Mapping EXP field and PFC into the PHBs 314 The mapping from EXP field of the shim header and PFC into the AF, EF 315 and DF PHBs is as follows: 317 EXP Field PHB PFC 319 000 -----> AFx1 AFCx 320 001 -----> AFx2 AFCx 321 010 -----> AFx3 AFCx 322 000 -----> EF EFC 323 000 -----> DF DFC 325 The AFCx and EFC per-hop forwarding classes (PFC) are defined in 326 [MPLS_DIFF_EXT]. The DFC (Default Forwarding Class) corresponds to the 327 PHB-group Forwarding Class for the DF PHB. 329 3 Examples of Local Policies for Determining PHBs 331 This section gives a few examples of the local policies, which might be 332 used in determining a packet's PHB. 334 3.1 Example of Determining an Egress packet's PHB Considering its 335 Previous PHB when DP Upgrading is not Permitted 337 In this example an egress packet's PHB is determined by examining the 338 EXP field of its shim header together with its previous PHB (which 339 might be determined from the packet's DSCP in case of non-MPLS egress 340 link or the shim header's lower label entry in case of MPLS egress 341 link of different hierarchical level), and assuming that no upgrading 342 of the DP of a packet is permitted. 344 EXP Field Previous New Comments 345 PHB PHB 347 000 AFx1 -----> AFx1 No change 348 000 AFx2 -----> AFx2 Impossible 349 000 AFx3 -----> AFx3 Impossible 350 000 EF -----> EF No change 351 000 DF -----> DF No change 352 001 AFx1 -----> AFx2 Downgrade 353 001 AFx2 -----> AFx2 No change 354 001 AFx3 -----> AFx3 Impossible 355 001 EF -----> EF Impossible 356 001 DF -----> DF Impossible 357 010 AFx1 -----> AFx3 Downgrade 358 010 AFx2 -----> AFx3 Downgrade 359 010 AFx3 -----> AFx3 No change 360 010 EF -----> EF Impossible 361 010 DF -----> DF Impossible 363 The following assumptions has been made in the above table: 365 - The drop precedence of a Marked packet can not be upgraded. 366 - the drop precedence of the EF and DF PHB packets can not be 367 downgraded. 369 3.2 Example of Determining an Egress Packet's PHB Considering its 370 Previous PHB when DP Upgrading is Permitted 372 In this example an egress packet's PHB is determined by examining the 373 EXP field of its shim header together with its previous PHB (which 374 might be determined from the packet's DSCP in case of non-MPLS egress 375 link or the shim header's lower label entry in case of MPLS egress 376 link of different hierarchical level), and assuming that upgrading of 377 the DP of a packet is permitted. 379 EXP Field Previous New Comments 380 PHB PHB 382 000 AFx1 -----> AFx1 No change 383 000 AFx2 -----> AFx1 Upgrade 384 000 AFx3 -----> AFx1 Upgrade 385 000 EF -----> EF No change 386 000 DF -----> DF No change 387 001 AFx1 -----> AFx2 Downgrade 388 001 AFx2 -----> AFx2 No change 389 001 AFx3 -----> AFx2 Upgrade 390 001 EF -----> EF Impossible 391 001 DF -----> DF Impossible 392 010 AFx1 -----> AFx3 Downgrade 393 010 AFx2 -----> AFx3 Downgrade 394 010 AFx3 -----> AFx3 No change 395 010 EF -----> EF Impossible 396 010 DF -----> DF Impossible 398 The following assumptions has been made in the above table: 400 - The drop precedence of a Marked packet can be upgraded. 401 - the drop precedence of the EF and DF PHB packets can not be 402 downgraded. 404 3.3 Example of Determining an Ingress ATM/FR Packet's PHB Considering 405 its previous PHB and CLP/DE bit when DP Upgrading is not Permitted 407 In this example an ingress packet's PHB is determined by examining its 408 CLP/DE bit (or in case of fragmented IP packets the logical "OR" of 409 CLP/DE bits of all fragments) together with its previous PHB (which 410 might be determined from the packet's DSCP in case of non-MPLS ingress 411 link or the shim header's top label entry in case of MPLS ingress link) 412 , and assuming that no upgrading of DP is permitted. 414 CLP/DE Previous New 415 bit EXP(PHB) EXP(PHB) Comments 417 0 000 (AFx1) -----> 000 (AFx1) No change 418 0 001 (AFx2) -----> 001 (AFx2) Impossible 419 0 010 (AFx3) -----> 010 (AFx3) Impossible 420 0 000 (EF) -----> 000 (EF) No change 421 0 000 (DF) -----> 000 (DF) No change 422 1 000 (AFx1) -----> 001 (AFx2) Downgrade 423 1 001 (AFx2) -----> 001 (AFx2) No change 424 1 010 (AFx3) -----> 010 (AFx3) No change 425 1 000 (EF) -----> 000 (EF) Impossible 426 1 000 (DF) -----> 000 (DF) Impossible 428 The following assumptions has been made in the above table: 430 - The drop precedence of a Marked packet can not be upgraded. 431 - ATM/FR links can downgrade the drop precedence of a packet by only 432 one level (i.e., AFx1 -> AFx2, not AFx3). 433 - the drop precedence of the EF and DF PHB packets can not be 434 downgraded. 436 3.4 Example of Determining an Ingress ATM/FR Packet's PHB Considering 437 its previous PHB and CLP/DE bit when DP Upgrading is Permitted 439 In this example an ingress packet's PHB is determined by examining its 440 CLP/DE bit (or in case of fragmented IP packets the logical "OR" of 441 CLP/DE bits of all fragments) together with its previous PHB (which 442 might be determined from the packet's DSCP in case of non-MPLS ingress 443 link or the shim header's top label entry in case of MPLS ingress link 444 ), and assuming that upgrading of DP is permitted. 446 CLP/DE Previous New 447 bit EXP(PHB) EXP(PHB) Comments 449 0 000 (AFx1) -----> 000 (AFx1) No change 450 0 001 (AFx2) -----> 000 (AFx1) Upgrade 451 0 010 (AFx3) -----> 001 (AFx2) Upgrade 452 0 000 (EF) -----> 000 (EF) No change 453 0 000 (DF) -----> 000 (DF) No change 454 1 000 (AFx1) -----> 001 (AFx2) Downgrade 455 1 001 (AFx2) -----> 001 (AFx2) No change 456 1 010 (AFx3) -----> 010 (AFx3) No change 457 1 000 (EF) -----> 000 (EF) Impossible 458 1 000 (DF) -----> 000 (DF) Impossible 460 The following assumptions has been made in the above table: 462 - The drop precedence of a Marked packet can be upgraded by only one 463 level (i.e., AFx3 -> AFx2 not AFx1). 464 - ATM/FR links can downgrade the drop precedence of a packet by only 465 one level (i.e., AFx1 -> AFx2, not AFx3). 466 - the drop precedence of the EF and DF PHB packets can not be 467 downgraded. 469 3. References 471 [ECN] Ramakrishnan et al., "A Proposal to add Explicit Congestion 472 Notification (ECN) to IP", RFC-2481, January 1999. 474 [MPLS_ARCH] Rosen et al., "Multiprotocol label switching Architecture", 475 work in progress, (draft-ietf-mpls-arch-04.txt), February 1999. 477 [DIFF_ARCH] Blake et al., "An architecture for Differentiated Services" 478 , RFC-2475, December 1998. 480 [MPLS_ENCAPS] Rosen et al., "MPLS Label Stack Encoding", work in 481 progress, (draft-ietf-mpls-label-encaps-03.txt), September 1998. 483 [DIFF_HEADER] Nichols et al., "Definition of the Differentiated 484 Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC-2474, 485 December 1998. 487 [MPLS_DIFF_EXT] Wu et al., "MPLS Support of Differentiated Services 488 by ATM LSRs and Frame Relay LSRs", work in progress, February 1999. 490 [DIFF_AF] J. Heinanen et al., "Assured Forwarding PHB Group", work in 491 progress, (draft-ietf-diffserv-af-06.txt), February 1999. 493 [DIFF-EF] V. Jacobson et al., "An Expedited Forwarding PHB", work in 494 progress, (draft-ietf-diffserv-phb-ef-02.txt), February 1999. 496 4. Authors' Addresses 498 Shahram Davari 499 PMC-Sierra Inc. 500 105-8555 Baxter Place 501 Burnaby, BC V5A 4V7 502 Canada 503 E-mail: Shahram_Davari@pmc-sierra.com 505 Ram Krishnan 506 Nexabit Networks 507 200 Nickerson Road, 508 Marlboro, MA 01752 509 USA 510 E-mail: ram@nexabit.com 512 Pasi Vanannen 513 Nokia 514 3 Burlington Woods Drive, Suit 250 515 Burlington, MA 01803 516 USA 517 Email: pasi.vaananen@ntc.nokia.com 518 Expires October 1999