IEEE C802.16g-05/025r2

Transcription

1 Prject IEEE Bradband Wireless Access Wrking Grup < Title A Generic Packet Cnvergence Sublayer (GPCS) fr Supprting Multiple Prtcls ver Air Interface Date Submitted Surce(s) Re: Abstract Purpse Ntice Release Lei Wang, Brian Petry, Yair Burlas, Kenneth Stanwd, Cygnus Cmmunicatins Inc. Phillip Barber, Huawei Vice: Fax: lwang@cygnuscm.cm bpetry@cygnuscm.cm yburlas@cygnuscm.cm kstanwd@cygnuscm.cm pbarber@bradbandmbiletech.cm This is a fllw-up cntributin n the prpsal f a generic packet cnvergence sublayer. As requested by g during the cmments reslutin discussins in sessin #39, we are submitting a fllw-up cntributin n ur Generic Packet Cnvergence Sublayer prpsal i.e., C802.16g-05/25, by presenting additinal supprting materials and integrating suggestins and cmments received frm ther members. We are cncerned that the prtcl cannt easily be extendable t transprt new prtcls ver the air interface. It wuld appear that a cnvergence sublayer is needed fr every type f prtcl transprted ver the MAC. Every time a new prtcl type needs t be transprted ver the air interface, the standard needs t be mdified t define a new CS type. We need t have a generic Packet cnvergence sublayer that can supprt multi-prtcls and which des nt require further mdificatin t the standard t supprt new prtcls. We believe that this was the riginal intentin f the Packet CS. Furthermre, we believe it is difficult fr the industry t agree n a set f CS s that all devices must implement t claim cmpliance. Generic Packet Cnvergence Sublayer (GPCS) slves these prblems. The purpse f this cntributin is t define a Generic Packet Cnvergence Sublayer fr Supprting Multiple Prtcls ver Air Interface. This dcument has been prepared t assist IEEE It is ffered as a basis fr discussin and is nt binding n the cntributing individual(s) r rganizatin(s). The material in this dcument is subject t change in frm and cntent after further study. The cntributr(s) reserve (s) the right t add, amend r withdraw material cntained herein. The cntributr grants a free, irrevcable license t the IEEE t incrprate material cntained in this cntributin, and any mdificatins theref, in the creatin f an IEEE Standards publicatin; t cpyright in the IEEE s name any IEEE Standards publicatin even thugh it may include prtins f this cntributin; and at the IEEE s sle discretin t permit thers t reprduce in whle r in part the resulting IEEE Standards publicatin. The cntributr als acknwledges and accepts that this cntributin may be made public by IEEE

2 Patent Plicy and Prcedures The cntributr is familiar with the IEEE Patent Plicy and Prcedures < including the statement "IEEE standards may include the knwn use f patent(s), including patent applicatins, prvided the IEEE receives assurance frm the patent hlder r applicant with respect t patents essential fr cmpliance with bth mandatry and ptinal prtins f the standard." Early disclsure t the Wrking Grup f patent infrmatin that might be relevant t the standard is essential t reduce the pssibility fr delays in the develpment prcess and increase the likelihd that the draft publicatin will be apprved fr publicatin. Please ntify the Chair <mailt:chair@wirelessman.rg> as early as pssible, in written r electrnic frm, if patented technlgy (r technlgy under patent applicatin) might be incrprated int a draft standard being develped within the IEEE Wrking Grup. The Chair will disclse this ntificatin via the IEEE web site < 2

3 A Generic Packet Cnvergence Sublayer Supprting Multiple Prtcls ver Air Interface 1. Backgrund As requested by g Task Grup during the cmments reslutin discussins in sessin #39, we are submitting a fllw-up cntributin n ur Generic Packet Cnvergence Sublayer (GPCS) prpsal i.e., C802.16g-05/25, by presenting additinal supprting materials and integrating suggestins and cmments received frm ther members. 2. References [ ] : IEEE-Std [16e/D12] : IEEE e/D12 [16cr1/D5] : IEEE cr1/D5 [16g-05/008r1] : IEEE g-05/008r1 3. Prblems with the Current Packet Cnvergence Sublayer This sectin describes sme prblems with the currently-defined packet cnvergence sublayers. 3.1.Nt Upper-Level Prtcl Agnstic A prblem with the standard is that it tries t address upper layer prtcl issues (see sectin 5.2 in ). Fr each upper layer prtcl, it defines hw fields in an upper layer prtcl header are used t determine the scheduling service type, and thus the cnnectin. And the standard ges further t define hw upper layer headers shuld be encded (e.g., cmpressed). Our cntentin is that such issues are best left utside the standard. The authrs cntend it is difficult fr the industry t accept a set f cnvergence sublayers that all devices must implement t be called cmpliant. Fr example, if Ethernet CS, why shuld a phne have t implement Ethernet frame frmats? And if IPv4: why shuld all devices need t participate in IP address assignment, IP mbility, tunneling, etc? And if a vendr implements a prprietary upper layer prtcl, hw can its layer be tested t be cmpliant? This cntributin suggests that a generic packet cnvergence sublayer can help by simplifying a cmpliance prfile that is independent f the upper layer prtcl. Other bdies such as the WiMAX Frum may benefit frm this simplificatin. By way f example, sme ther (successful) link-layer prtcl standards which d nt address upper layer prtcl-header-mapping, encding and cmpressin are: 802.3, 802.2, , Frame Relay and packet-ver- SONET (POS) embdied in Generic Framing Prcedures f ITU-T G.7041/Y Als, sme yet-t-besuccessful link prtcls fllw the same cnventin f leaving the upper layer standards bdy t define its encapsulatin: Infiniband, (Resilient Packet Ring). Fr instance, IP datagram encding and cmpressin fr specific link layers is typically left fr the IETF t define. A simple example t cnsider is IP ver Ethernet, which is fairly well understd. The IEEE and standards d nt define hw IP packets are mapped t Ethernet links r hw IP addresses are assigned r mapped t Ethernet destinatin addresses. Thse functins are specifies by the cmmunity, using the wellknwn prtcls ARP and DHCP. Ethernet has a simple way f transprting pririty bits (P-bits) in each packet (see 802.1Q) and QS-aware Ethernet switches use them t schedule packets in the presence f cngestin. But 802.1Q des nt specify hw the IP layer uses the P-bits. Similarly, we d nt think

4 needs t specify hw IPv4 TOS and DSCP fields map t scheduling service types (see sectin , sectin ). Hwever, the authrs f this cntributin recgnize that Ethernet-based QS tk a lng time t get right, and recgnize the effrts f t get it right the first time. Other example IETF RFCs that explain hw IP uses a link layer prtcl are RFC2464 Transmissin f IPv6 Packets ver Ethernet Netwrks, RFC2625 IP and ARP ver Fibre Channel, RFC2516, A methd fr transmitting PPP ver Ethernet (PPPE). Als refer t wrk currently under way in the IETF wrking grups, IP-ver-Infiniband (ipib) and IP-ver-Resilient Packet Ring (iprpr). 3.2.N Standard Service API The standard nt des specify a thrugh MAC service API. Althugh the MAC SAP is present in Figure 1 f (cpied belw, Figure 1), the MAC service definitin fund in Annex C is infrmative rather than nrmative. Instead f a standard service interface definitin, prefers t define cnvergence with upper layer prtcls. We think the reasn the standard instead chse the cnvergence layer apprach was t fster interperability by explicitly stating hw upper layers QS definitins must map t scheduling and security services. While this was a nble gal, we think it turned ut t be t cmplicated and the standard as it stands nw des nt define all the prcedures necessary t build many types f interperable systems. A standardized service API wuld prvide a clean way t expse services t the next layer in a prtcl stack, r t aware applicatins. Citatins f sme ther MAC-layer service APIs are: sectin 2, the MSAP cncept in IEEE Std (Figure 1), IEEE Std , 1999, sectin 6.2. The GPCS can prvide access t a standard service API fr the case when all classificatin functins is NULL. Nte this is equivalent t what used t be defined as N Cnvergence Sublayer befre it was remved in IEEE cr1/D5. Hwever, GPCS des nt attempt t define a standard service API. 4 Figure 1: Layering Mdel (cpied frm )

5 3.3.Only One Upper Prtcl per Service Flw (per Cnnectin) The cnvergence sublayers d nt define the capability fr multiple upper layer prtcls t transprt the SDUs n a single service flw (cnnectin). A service flw, identified by a cnnectin ID (CID), is a valuable resurce in bth base statins and subscriber statins. An system shuld nt be frced t pen a different CID fr each upper layer prtcl if packets fr upper layer prtcls have the same QS requirements ( scheduling service types). The generic cnvergence sublayer prvides a simple way t transprt multiple prtcls ver a single cnnectin. 3.4.Pr Extendibility It wuld appear that a cnvergence sublayer (CS) is needed fr every type f prtcl transprted ver the MAC. Every time a new prtcl type needs t be transprted ver the air interface, the standard needs t be mdified t define a new CS type. A gd example f the prliferatin f CS s is fund in Sectin CS Specificatin. In e/D12, there are 4 new cnvergence sublayers that have been added in rder t supprt IP r Ethernet/802.3 with IETF IETF header cmpressin prtcls ROHC and ECRTP. This is in additin t the 8 Cnvergence Sublayers already defined in , that brings the ttal f Cnvergence Sublayers in e t 12! shuld define an access methd that allws fr ff-the-shelf cmpnents, thse nt even aware f , such as bridges, ruters, NAT gateways, and classificatin engines t be used as cmpnents t build cmpliant systems. Fr instance, bridges can perate just n 48-bit MAC addresses and lgical prt numbers, ruters perate n IP addresses and lgical prt numbers, NAT gateways translate IP headers withut knwledge f underlying link technlgies, and classificatin subsystems can perate n a variety f upperlayer prtcl packets t identify QS flws. Since the existing cnvergence sublayers attempt t define upper layer prtcl header interpretatin, the layer needs t change whenever upper layer systems are enhanced. This mdel is nt extensible SAP layering shuld attempt t islate itself frm upper layers s upper layers can be enhanced in standardized r prprietary was and still perate effectively ver Repeating Upper Layer Functins In the current specificatin, address-based classificatin rules define hw data packets f different users are mapped t different service flws (cnnectins with CIDs), s that the differentiated QS and/r security prvisins can be prvided. Particularly, it is critical fr the dwnlink (DL) because the BS typically wuld use the address-based classificatin rules t map each packet t a different SS/MS in a pint-t-multipint tplgy. The address-based classificatin rules require the current cnvergence sublayer t maintain the mapping infrmatin between upper-prtcl-defined addresses (e.g., IP r Ethernet) and CIDs. This ultimately frces the CS t implement sme upper layer functins. Fr example, the IPv4 CS at BS maintains a mapping state fr IP addresses t CIDs. Whenever there is a change in IP addresses, the mapping state needs t be updated. In nn systems and prtcl stacks, upper layer address assignment and mapping t link layer entities is typically part f a ruting functin at the netwrk layer. A truble with Ethernet headers is the size. S has attempted t define a CS PDU frmat t deal with cmpress-header Ethernet PDUs (see sectin f IEEE e/D12. Fields in the Ethernet header and additinal fields inside the Ethernet paylad (e.g., IP header and IP with mbile-ip header) cmplicate the classificatin prcess. Rather than pull-in Ethernet classificatin t , it wuld seem better t enable a system t classify an Ethernet packet befre it is cmpressed. GPCS leaves the chice f classificatin methd 5

6 utside f Since upper layer prtcl (ULP) addresses are used fr sme packet CS classificatin rules, the packet CS layers must participate in upper layer prtcl address-management prcedures. When a ULP system changes addresses (mbility re-registratin), translates addresses (NAT) r tunnels with nested headers (IPsec and Mbile IP), the packet CS must be infrmed f changes t maintain cnsistent classificatin. The authrs cntend when layers intertwine, it is difficult t write a specificatin that serves a wide enugh variety f implementatin and ULP layering ptins, and eventually industry interperability will suffer. Als, nte that 802.1D bridging can be implemented ver withut Ethernet cnvergence. Fr instance, a BS can implement a bridge f VLANs between resilient packet ring and a set f nn-ethernet-capable subscribers shuld nt preclude the cnfiguratin f such tplgies. The authrs f this cntributin cntend that althugh Ethernet Packet CS is great fr certain classes f devices, interperable cnvergence is difficult t define because there are s many implementatin alternatives. S, Ethernet usage is best left t define abve s an Ethernet-based device can claim cmpliance whether it implements standard Ethernet Packet CS r prprietary Ethernet CS shuld nt define the use f Ethernet, r preclude flexibility in prprietary implementatins. 3.6.Lack f Supprt fr Multiple Header Cmpressin Schemes Furthermre, we see an architectural issue related t header cmpressin prtcls. Fr example, ROHC cmpresses all the infrmatin used by t classify a packet t a CID and thus requiring that the implementatin f ROHC (frm standardizatin perspective at least) must be dne after the classificatin and thus within the prtcl stack. Nte that e/D12 attempts t define classificatin methds fr multiple header cmpressin schemes. But it des nt allw the use f prprietary header cmpressin methds. The authrs f this cntributin claim that inclusin, and even mentin, f header cmpressin schemes, ver-cmplicates the standard and leaves the standard in a state where new header cmpressin schemes frce revisin f the standard. We think this will ultimately cnfuse the industry, and cmplicate cmpliance and interperability tests. The standard shuld allw fr any header cmpressin scheme t claim cmpliance. Still, cmpatible and interperable header cmpressin needs t be defined, and classificatin methds need t be implemented. But the authrs f this cntributin cntend the prcedures d nt need t be defined in the standard. 4. Generic Packet Cnvergence Sublayer (GPCS) T address prblems with the current packet cnvergence sublayer, cited in sectin 3, we prpse a Generic Packet Cnvergence Sublayer (GPCS), defined as fllws: GPCS prvides a generic packet cnvergence layer. This layer uses the MAC SAP (see Annex C) and expses a new SAP t GPCS applicatins GPCS des nt re-define r replace ther cnvergence sublayers. Instead, it prvides a SAP that is nt prtcl specific The basic functin f the GPCS is still classificatin. It participates in the prcess t map upper layer packets (carried in MAC SDUs) t apprpriate cnnectins. But with GPCS, upper layer packet parsing (header inspectin and interpretatin t lcate and extract fields relevant t classificatin rules) happens abve GPCS. The results f packet parsing are classificatin parameters given t the GPCS SAP fr parameterized classificatin, but upper layer packet parsing is left t the GPCS applicatin 6

7 GPCS defines a set f SAP parameters as the result f upper layer packet parsing. These are passed frm upper layer t the GPCS in additin t the data packet. Each is defined in later sectins f this cntributin LOGICAL_PORT_ID COS_ID (Class f Service ID) PROTOCOL_TYPE GPCS prvides an ptinal way t multiplex multiple layer prtcl types (e.g., IPv4, IPv6, Ethernet) ver the same cnnectin/service flw. We call this MULTIPROTOCOL_- ENABLE, a feature which can ptinally be activated per CID Fr vendrs t build interperable equipment, each upper layer prtcl type needs an interface specificatin (e.g., IPv4 ver , r Ethernet ver ). Such a standard specificatin can be develped by r any ther standard bdies, e.g., WiMAX, r IETF. Essentially, sme f thse specificaitns culd be equivalent in functin t prtcl-specific packet cnvergence sublayers defined in tday s standard. Upper layers layers IP Ethernet... abc SAP SAP SAP IPv4 CS Ethernet CS MAC abc CS Upper layers layers IPv4 ver 16 Ethernet ver D Bridge IP Ethernet abc 802.1D Over SAP abc ver GPCS MAC X Y... Multiple prtcls ver 16 Z PHY PHY (a) Prtcl structure with the service-specific Packet Cnvergence Sublayer (b) Prtcl structure with the prpsed Generic Packet Cnvergence Sublayer (GPCS ) Figure 2: GPCS Layering Mdel Figure 2 illustrates GPCS laying similarity t existing packet CS layers. Such a prtcl structure f link layer interface t the upper layers has been widely used in sme successful link layer prtcl standards, e.g., 802.3, 802.2, , , Frame Relay, etc. Cmparing t the current packet cnvergence sublayer, the prpsed GPCS: 1. Decuples the link layer frm the higher layers prtcls thus enabling the transprt f new multiple upper layer prtcl data ver air interface withut requiring any mdificatins t prtcl 7

8 2. Allws the CS t cnduct the classificatin functin withut the need t interpret (parse) upper layer prtcl headers, by allwing the higher layers prtcls t pass sme available infrmatin t the CS 3. Avids the repetitins f upper layer functins at the CS 4. Allws multiple prtcls ver the same MAC cnnectin 5. Significantly simplifies the cmfrmance test f the packet cnvergence sublayer, by pushing the slutins t these prblems t the upper layer. Althugh the generic cnvergence sublayer des nt slve interperability issues fr Ethernet-bridging-riented devices, r IPv4- riented devices, GPCS prvides pprtunities fr experts f upper prtcls, e.g., experts frm Ethernet cmmunity and experts frm IP cmmunity such as IETF, t review and adpt standards fr using t transprt IP with differentiated services. Simple devices that have neither Ethernet nr IP, nr ne f the dzen cnvergence sublayers, can use with GPCS and be called cmpliant with A Generic Packet Cnvergence Sublayer (GPCS) wuld allw us t decuple the link layer prtcl frm the higher layer prtcls. In ther wrds, instead f frcing t knw much abut all the prtcls it caries and pssibly repeat sme f the higher layers prtcls functins within the layer, the higher layers prtcls need nly t pass few parameters t enable t classify the SDU. T enable upper prtcl independence, we prpse tw parts: parameters fr the SAP fr the cnvergence sublayer, and an ptin per-sdu field prepended t each MAC SDU. 4.1.SAP Parameters The prpsed GPCS SAP parameters enable the upper layer prtcl t generically specify services withut the need fr the layer t interpret upper layer prtcl headers. In ther wrds, since the SAP parameters are explicit, the parsing prtin f the classificatin prcess is the respnsibility f the upper layer. The SAP parameters need t be specified in the standard t prvide an interface pint where cmpliance can be measured independent f the upper layer prtcl type (Ethernet, IPv4, etc.). Figure 3 depicts the GPCS SAP parameters mdel. The figure intends t shw hw GPCS parameters are chsen in a system. It illustrates that LOGICAL_PORT_ID and COS_ID abstractins can be implementatinspecific, lcally-defined cnstructs. We d nt think that LOGICAL_PORT_ID and COS_ID need t have cde-pints assigned and each cde-pint usage explained in a standard. The reasn fr such abstractin is t enable a wide variety f system cnfiguratins abve the GPCS SAP that can be cmbined in varius ways. Off-the-shelf cmpnents and subsystems can prvide bridging, ruting and parsing functins withut adhering t a standard. The number f bits and numeric assignments f thse parameters are left t the implementatin. Since the GPCS SAP carries abstract parameters, GPCS SAP cmpliance des nt require specific parameter values be standardized. Rather, cmpliance must be measured by the results f GPCS classificatin. Fr instance, the GPCS layer in a given vendr s system generates a CID with a certain security prfile and scheduling service type under knwn cnditins, emplying either standard packet-parsing cnvergence r a prprietary methd. A cmpliance tester can then validate that the CID s security prfile is perating crrectly and the scheduling service is delivering the required thrughput and latency. With GPCS, 802.6/GPCS cmpliance can be tested independently f specific upper layer classificatin methds. Withut GPCS, must define cnvergence and classificatin fr each methd that deserves interperability and thus cmpliance. Cnsidering the variety f pssible upper layer prtcl stack cnfiguratins, and the pssibility f prprietary methds, it is difficult if nt impssible fr all deserving systems t claim cmpliance withut GPCS. Nte that Figure 3 des nt shw where header cmpressin is perfrmed. We believe that header cmpressin is a facility that is rthgnal t classificatin and is best defined separately frm the cnvergence prcess. Fr 8

9 COS_ ID IEEE C802.16g-05/025r2 example, a system implementing IPv4 with ROHC culd implement header cmpressin in the Upper Layer Prtcl r a cmpressr engine culd be inserted just belw the Parser/Classifier. Either cnfiguratin culd result in an ROHC-interperable system. Als nte that a system culd define a null functin fr Destinatin Lkup, Parser/Classifier and even Generic Classifier. The upper prtcl, r applicatin in such a system must be aware and prvide direct access t the MAC SAP. Fr instance, a vide-ver device need nt define Ethernet r IP cnvergence functin. Other standards culd build n GPCS, and prprietary systems culd be defined. Such systems culd be called Classificatin Free. The authrs think it wuld be great if they all culd achieve cmpliance withut requiring mdificatins t the standard. Upper Layer Prtcl Packet PROTOCOL_TYP E Destinatin Lkup (ruting) e.g., Surce, Destinatin, TCP Prt Number, VLAN tag, etc. The System knws the prtcl type A rute and /r bridge lkup engine. It fund ut abut end pints after registratin and service flw establishment Packet PROTOCOL _TYPE LOGICAL _PORT_ID Parser/Classifier Chses a lcallydefined prt number Can emply any frm f packet inspectin t determine class f service GPCS SAP Packet LOGICAL _PORT_ID PROTOCOL _TYPE GPCS Chses a lcallydefined class-fservice ID Des nt parse the packet, but perates nly n parameters E.g., Appendix C MAC SAP CID SDU Scheduling Service SF Prfile, including UGS, BE, rtps, nrtps, extended rtps Figure 3: GPCS SAP Parameters Mdel GPCS defines SAP parameters abstractly because the authrs think their use in a lcal system is utside the scpe f the standard. Fr instance, bit width, cde pints, errr checking, prgramming language and perating system bindings are nt specified. But PROTOCOL_ID, which since it can ptinally be transmitted between end pints, needs t have cde pints assigned (such as Ethernet, PPPE, IPv4, IPv4-ROHC, IPv6, etc.). 9

10 Upper Layer Prtcl Packet De-Mux Functin Has a table t lkup ULP SAP frm PROTOCOL _TYPE GPCS SAP Packe t PROTOCOL_TYPE GPCS Extracts PROTOCOL _TYPE frm DSX cntext r frm SDU E.g., Appendix C MAC SAP SDU CID MAC SAP Parameters: Figure 4: PROTOCOL_TYPE Usage by Receiver PROTOCOL_TYPE. The prtcl type field identifies the upper layer prtcl that is immediately abve the prtcls. If MULTI_PROTOCOL_ENABLE is activated, the PROTOCOL_TYPE shall be als carried ver-the-air in every SDU, s the receiver can demultiplex an SDU and invke the apprpriate upper layer prtcl. If MULTIPROTOCOL_ENABLE is nt activated, an CID can carry nly ne prtcl type, and the PROTOCOL_TYPE field is nly cmmunicated during cnnectin establishment. It is thus analgus t the ethertype field in an Ethernet packet ( assignments/ethernet-numbers) r the 16-bit PPP data link (DL) layer prtcl field in PPP packets ( 1. The authrs recmmend that start a new IANA registry f GPCS prtcl numbers. Nte that the Ethernet numbers prbably shuld nt be used because it has n Ethernet cde pint which culd mean Ethernet-ver PPP prtcl numbers aren t gd either because althugh they include Ethernet, ROHC, IP, etc., it des nt include a prtcl number fr PPP. Nte that GPCS with MULTIPROTOCOL_ENABLE is just abut like Ethernet Packet CS except n Ethernet addresses are transprted. LOGICAL_PORT_ID. A link prt number that is utput frm a bridging r ruting functin. It is lcally assigned and nt exchanged between end-pints. Fr instance, an 802.1D bridge agent in a BS culd discver a service flwcnnectin t a specific SS and assign a LOGICAL_PORT_ID number t that service flwcnnectin plus SS entity. The LOGICAL_PORT_ID can thus becme a destinatin link fr an 802.1D bridge. It culd transact spanning tree and GARP messages and relay and filter packets based n 48-bit 802 MAC addresses and VLAN tags. The exact mechanism fr hw this is dne is left t the implementatin. In 802.1D terminlgy, the LOGICAL_PORT_ID culd be called a Bridge Prt ID, which a lcally-assigned number. Nte that the prcess fr service flwcnnectin establishment n the air interface is defined in , but apart frm Annex C, the end-pint s prcess t cmmunicate service flws and cnnectins is nt. An 802.1D cmpliant bridge can implement SS and service flwcnnectin discvery hwever it needs t, and 802.1D-bridging-ver can still be standardized and 1 Nte the wide variety f header-cmpressin prtcl types defined fr PPP. Since PPP is intended fr bandwidth-cnstrained links, it seems t have very similar header cmpressin requirements as Als nte the set f cde pints defined fr varius bridging functins. 10

11 interperable. COS_ID (Class f Service ID). A class f service identifier utput frm a packet-parsing classificatin functin. The class f service culd simply identify an scheduling service type. Alternatively, a system culd define it as a superset f scheduling services, and perfrm lcal scheduling and/r queuing based n the value. S, instead f specifying COS_ID t mean exactly the scheduling service type, it is left as an abstract lcally-defined identifier. In either case, an implementatin f the Generic Classifier takes the COSD_ID as input and uses it t determine a CID with matching scheduling services. MULTI_PROTOCOL_ENABLE. This parameter is nt shwn in Figure 3. A lcal system can ptinally chse t activate this feature t enable multiple PROTOCOL_TYPEs t be carried ver a single CID. MULTI_PROTOCOL_ENABLE is useful fr devices that are cnstrained t implement a small number f CIDs yet need t carry a variety f prtcls using the same scheduling service type. Fr instance, a single best-effrt (BE) cnnectin culd carry statistically multiplexed packets f IPv6, IPv6-ROHC and Ethernet PROTOCOL_TYPEs. SDU and Length. GPCS has SDU and SDU-length parameters, which are the same as the crrespnding parameters in Annex C, MAC_DATA.request and MAC_DATA.indicatin. 5. Applicatin Examples f the Prpsed Generic Packet CS (GPCS) This sectin describes sme examples f hw GPCS is used, particular fr tw upper prtcls that have lts f interest: Ethernet packets, IPv4, and ROHC header cmpressin. 5.1.IPv4-ROHC ver GPCS IP Mbility, Ruting, etc. Outside f GPCS. Can be prprietary. Can be specified by IP-ver Standard r Recmmended practice IP Datagram IP Classificatin Prcess IP Header Cmpressin (e.g., ROHC) Maps IP addresses, TOS/ DSCP field, etc. LOGICAL_ PORT_ID, COS_ID, PROTOCOL_TYPE =IPv4_ROHC Header-Cmpressed IP Datagram GPCS SAP SDU Generic Cnvergence Scheduling Service Figure 5: IPv4-ROHC ver GPCS Figure 5 illustrates an example lcal stack transmit prcess. An IP endpint r ruter typically needs t map a destinatin IP address t an egress link and destinatin MAC address. Fr Ethernet, many systems have an IP rute lkup prcess and address reslutin (ARP) prcess. Same fr An BS can implement an IP rute prcess, alng with SS discvery and ARP if 11

12 necessary. Whatever the prcess, standards-based r prprietary, the utput f rute and address reslutin is a LOGICAL_PORT_ID which identifies a lcal path frm the IP entity t the egress radi fr a subscriber statin. Nte that an implementatin can emply a separate rute engine t help (even a separate, ff-the-shelf, nn aware IP ruter subsystem), r can cmbine IP packet classificatin (parsing and inspectin) with ruting. The parsing and inspectin prcess results in a COS_ID. It may parse single-ip headers, tunneled IP-in-IP headers (e.g., fr IP mbility), and even cmbine netwrk address translatin functins. As with ruting, standard ff-the-shelf subsystems may be emplyed t chse an apprpriate, lcally-defined COS_ID. Header cmpressin can be perfrmed anywhere abve the GPCS SAP. In the figure, it is shwn last, which may make sense fr sme systems that translate headers during the packet inspectin prcess. Rbust Header Cmpressin (ROHC) (see IETF RFC 3095) can use GPCS. It shuld have its wn prtcl type, such as IPv4-ROHC s a receiver can knw t apply the ROHC algrithm. Other header cmpressin techniques can als be used, such as the riginal Van Jacbsen TCP/IP header cmpressin, RFC1144. If MULTIPROTOCOL_ENABLE is activated, GPCS requires the transmitter inserts its prtcl type (IPv4) as an extended subheader entry s the receiver can de-multiplex: chse the right upper prtcl entity (receive SAP). The Generic Classifier implements a lcally-defined functin t map PROTOCOL_TYPE (IPv4-ROHC), LOG- ICAL_PORT_ID, and COS_ID t an apprpriate CID. Fr example, LOGICAL_PORT_ID culd be an index t a table in which each entry has a pinter a subscriber statin s table f available service classes. COS_ID culd be service-class index t a table f CIDs fr the subscriber. 5.2.Ethernet ver GPCS Outside f GPCS. Can be prprietary. Can be specified by Ethernet -ver Standard r Recmmended practice Ethernet Packet Ethernet Classificatin Prcess Header Cmpressin Maps Ethernet addresses, and/r 802.1Q P bits, VLAN tag LOGICAL_PORT_ID, COS _ID, PROTOCOL _TYPE =Ethernet GPCS SAP Header-Cmpressed Ethernet Packet SDU Generic Cnvergence Scheduling Service D,Q Bridging ver GPCS Figure 6: Ethernet ver GPCS Figure 7 is cpied frm IEEE 802.1Q-2003, which shws participating in an bridged-lan envirnment. The authrs f this cntributin cntend that the MAC shuld supprt bridging in a generic way. By generic, we mean shuld nt require a system t emulate anther MAC and/r frame frmats f ther MACs, such as 802.3, but shuld ffer service t the bridging prtcls (802.1D, 802.1Q). 12

13 Figure 7: Bridging -- Standards Relatinships Hwever, GPCS by itself des nt specify hw bridge prtcls are integrated with particularly with respect t service flw and cnnectin establishment and discvery. The cntributrs had a desire t prpse a baby step t simplify layering, but nt a desire t slve the bridging issues. Even s, the g specificatin culd use GPCS t further define hw bridging uses GPCS. Figure 8 shws an example 802.1D LAN with 4 ndes. Fllwing are sme issues t slve: 1. GPCS des nt specify all service access pint (SAP) primitives fr LAN-specific service flw r cnnectin establishment 2. GPCS des nt recmmend hw a bridge uses bradcast and multicast service flwscnnectins t relay bridged packets: a. Multicast service flwcnnectin discvery r establishment. The bridging entity needs t be infrmed f service flwcnnectins. Regarding GPCS, it shuld nly care abut MAC address, LOGICAL_PORT_ID and COS_ID b. Map VLAN IDs t CIDs that participate in a crrespnding 802.1Q multicast grup (if multicast is desired) c. Map 802.1Q pririty t GPCS COS_ID d endpint discvery. An 802.1D bridge makes its relay decisins based n 48-bit MAC addresses (typically uses the destinatin MAC address). When a bridge has a packet destined fr and endpint nde (identified by destinatin MAC address), but des nt knw which prt will reach the endpint, the bridge can emply bradcast r multicast r ther prcedures particular t the MAC layer. 3. Define SAP primitives t expse SS/MS MAC addresses t the bridge relay. Fr instance, an MS culd be an endpint (nt a bridge). The bridge functin n the BS-side (r ASN) needs t knw the mapping f the endpint s MAC address t a lgical link number, and therefre t a service flwcnnectin. Further, a VLAN-capable bridge needs t maintain a mapping f the MAC address t VLAN IDs. 13

14 RTP RTP RTP UDP UDP UDP IP IP IP-ver-GPCS IP Ruter 802.1D Bridge D, Q Bridge A B Bridge-ver GPCS C GPCS Bridge-ver GPCS D SONET Ethernet Air Interface A B C D Ethernet Nde. MAC address A Ethernet Nde. MAC address B Nde. MAC address C Ethernet Nde. MAC address D SS/MS SS/MS BS/ASN 6. Suggested Changes Figure 8: Example LAN with 4 endpint ndes: A, B, C, D In g-05/008r1, we prpse the fllwing changes (new text in blue): 1. page 3 replace line 1 t line 52 by the fllwing text: 5. Service-Specific CS 5.2 Packet CS [insert new subclause and subsequent test belw] Generic Packet Cnvergence Sublayer (GPCS) The Generic Packet CS (GPCS) is a upper layer prtcl-independent packet cnvergence sublayer that supprts multiple prtcls ver air interface. It is defined as fllws: GPCS prvides a generic packet cnvergence layer. This layer uses the MAC SAP and expses a new SAP t GPCS applicatins GPCS des nt re-define r replace ther cnvergence sublayers. Instead, it prvides a SAP that is nt prtcl specific The basic functin f the GPCS is still classificatin. It participates in the prcess t map upper layer packets (carried in MAC SDUs) t apprpriate cnnectins. But with GPCS, packet parsing happens abve GPCS. The results f packet parsing are classificatin parameters given t the GPCS SAP fr parameterized classificatin, but upper layer packet parsing is left t the GPCS applicatin 14 GPCS defines a set f SAP parameters as the result f upper layer packet parsing. These are passed frm upper layer t the GPCS in additin t the data packet. Each is defined in sectin LOGICAL_PORT_ID COS_ID (Class f Service ID) PROTOCOL_TYPE GPCS prvides an ptinal way t multiplex multiple layer prtcl types (e.g., IPv4, IPv6,

15 Ethernet) ver the same cnnectin/service flw. A TLV parameter, MULTIPROTOCOL_ENABLE, is defined in the DSx messages t enable/disable this feature. Fr interperability, each upper layer prtcl type needs an interface specificatin (e.g., IPv4 ver , r Ethernet ver ). Such a standard specificatin is ut f scpe f the GPCS. [XXX: take ut cmparisn frm diagram] Upper layers layers IP Ethernet... abc SAP SAP SAP IPv4 CS Ethernet CS MAC abc CS Upper layers layers IPv4 ver 16 Ethernet ver D Bridge IP Ethernet abc 802.1D Over SAP abc ver GPCS MAC X Y... Multiple prtcls ver 16 Z PHY PHY (a) Prtcl structure with the service-specific Packet Cnvergence Sublayer (b) Prtcl structure with the prpsed Generic Packet Cnvergence Sublayer (GPCS ) Figure 17c: GPCS Layering Mdel GPCS Service Access Pint (SAP) Parameters The GPCS SAP parameters enable the upper layer prtcls t generically pass infrmatin t the GPCS s that the GPCS des nt need t interpret upper layer prtcl headers in rder t mapping the upper lateyrr data packets int prper MAC cnnectins. Since the SAP parameters are explicit, the parsing prtin f the classificatin prcess is the respnsibility f the upper layer. The parameters are relevant fr SAP data path primitives, GPCS_DATA.request and GPCS_DATA.indicatin. [Nte t editr: cpy specificatin methd frm Annex C t this sectin t describe GPCS_DATA primitives and SAP parameters.] There are fur GPCS SAP parameters: LOGICAL_PORT_ID, COS_ID, PROTOCOL_TYPE, and MULTI_PROTOCOL_ENABLE. Figure 17d depicts the GPCS SAP parameters mdel. It shws hw the first three GPCS parameters, LOGICAL_PORT_ID, COS_ID, and PROTOCOL_TYPE, can be chsen in a system. The parameter, MULTI_PROTOCOL_ENABLE, is required fr signaling whether r nt the multiple prtcl packets are transmitted n the same CID. 15

16 COS_ ID IEEE C802.16g-05/025r2 Upper Layer Prtcl Packet PROTOCOL_TYPE Destinatin Lkup (ruting) e.g., Surce, Destinatin, TCP Prt Number, VLAN tag, etc. The System knws the prtcl type A rute and /r bridge lkup engine. It fund ut abut end pints after registratin and service flw establishment Packet PROTOCOL _TYPE LOGICAL _PORT_ID Parser/Classifier Chses a lcallydefined prt number Can emply any frm f packet inspectin t determine class f service GPCS SAP Packet PROTOCOL _TYPE GPCS LOGICAL _PORT_I D Chses a lcallydefined class-fservice ID Des nt parse the packet, but perates nly n parameters E.g., Appendix C MAC SAP SDU CID Scheduling Service SF Prfile, including UGS, BE, rtps, nrtps, extended rtps Figure 17d: GPCS SAP Parameters Mdel Upper Layer Prtcl Packet De-Mux Functin Has a table t lkup ULP SAP frm PROTOCOL _TYPE GPCS SAP Packe t PROTOCOL_TYPE GPCS Extracts PROTOCOL _TYPE frm DSX cntext r frm SDU E.g., Appendix C MAC SAP SDU CID MAC Figure 9: PROTOCOL_TYPE Usage by a Receiver 16

17 PROTOCOL_TYPE. The prtcl type field identifies the upper layer prtcl that is immediately abve the prtcls. If MULTI_PROTOCOL_ENABLE is activated, the PROTOCOL_TYPE shall be als carried ver-the-air in every SDU, s the receiver can demultiplex an SDU and invke the apprpriate upper layer prtcl. If MULTIPROTOCOL_ENABLE is nt activated, an CID can carry nly ne prtcl type, and the PROTOCOL_TYPE field is nly cmmunicated during cnnectin establishment thrugh DSx messages. It is thus analgus t the ethertype field in an Ethernet packet r the 16-bit PPP data link (DL) layer prtcl field in PPP packets. The GPCS can either uses the IANA t assign 2- byte PROTOCOL_TYPE numbers, r maybe just brrw the number space frm PPP. Nte that GPCS with MULTIPROTOCOL_ENABLE is just abut like Ethernet Packet CS except n Ethernet addresses are transprted, and s they dn t need t be header-cmpressed. LOGICAL_PORT_ID. [XXX: be mre cncise---dn t talk abut 802.1D] A prt number that is utput frm a bridging r ruting functin. It is lcally assigned and nt exchanged between air link. Fr instance, an 802.1D bridge agent in a BS culd discver a service flwcnnectin t a specific SS and assign a LOGICAL_PORT_ID number t that service flwcnnectin plus SS entity. The LOGICAL_PORT_ID can thus becme a destinatin prt fr an 802.1D bridge. It culd transact spanning tree and GARP messages and relay and filter packets based n 48-bit 802 MAC address and VLAN tags. The exact mechanism fr hw this is dne is beynd the scpe f the GPCS. COS_ID (Class f Service ID). A class f service identifier utput frm a packet-parsing classificatin functin. The class f service culd simply identify an scheduling service type. Alternatively, a system culd define it as a superset f scheduling services, and perfrm lcal scheduling and/r queuing based n the value. S, instead f specifying COS_ID t mean exactly the scheduling service type, it is left as an abstract lcally-defined identifier. In either case, the GPCS takes the COD_IDCOS_ID as input and uses it t determine a CID with matching scheduling services. MULTI_PROTOCOL_ENABLE. This parameter is nt shwn in Figure 17d. A lcal system can ptinally chse t enable/disable multiple PROTOCOL_TYPEs t be carried ver a single CID. MULTI_PROTOCOL_ENABLE is useful fr devices that are cnstrained t implement a small number f CIDs yet need t carry a variety f prtcls using the same scheduling service type. Fr instance, a single best-effrt (BE) cnnectin culd carry statistically multiplexed packets f IPv6, IPv6-ROHC and Ethernet PROTOCOL_TYPEs DATA. SDU data reference t a number f bytes delivered by the GPCS upper layer t GPCS, r by GPCS t the upper layer. LENGTH. Number f bytes in DATA GPCS PDU Frmat There are tw different frmats f the GPCS PDU depending n the parameter value f MULTIPROTOCOL_- ENABLE, as shwn in Figure 17e. PROTOCOL_TYPE indicates the utermst prtcl f the SDU. It is 16- bit number assigned frm a set f pssible values f the PPP data link (DL) layer prtcl numbers. This space f numbers is maintained by the IANA. It shall be cmmunicated t the MAC receiver in every SDU if MULTIPROTOCOL_ENABLE is enabled fr a CID. GPCS SDU (a) GPCS PDU frmat with MULTIPROTOCOL_ENABLE Disabled 17

18 PROTOCOL _TYPE (16b) GPCS SDU (b) GPCS PDU frmat with MULTIPROTOCOL_ENABLE Enabled Figure 17e: GPCS PDU frmats Sent t the MAC SAP frm the GPCS 2. page 5, line 49, replace frm page 5 line 40 t page 8 line37 by the fllwing text: CS specific service flw encdings CS specificatin Type Length Value [145/146] : N CS GPCS (Generic Packet Cnvergence Sublayer) 1: Packet, IPv4 2: Packet, IPv6 3: Packet, 802.3/Ethernet 4: Packet, 802.1Q VLAN 5: Packet, IPv4 ver 802.3/Ethernet 6: Packet, IPv6 ver 802.3/Ethernet 7: Packet, IPv4 ver 802.1Q VLAN 8: Packet, IPv6 ver 802.1Q VLAN 9: ATM 10: Packet, 802.3/etherneta with ROHC header cmpressin 11: Packet, 802.3/ethernetb with ECRTP header cmpressin 12: Packet, IP2 with ROHC header cmpressin 13: Packet, IP2 with ECRTP header cmpressin 10 14~255: reserved Scpe DSx-REQ CS Parameter encding rules CST CS 98 N CS GPCS (Generic Packet Cnvergence Sublayer) 99 ATM 100 Packet, IPv4 101 Packet, IPv6 102 Packet, 802.3/Ethernet 103 Packet, 802.1Q VLAN 104 Packet, IPv4 ver 802.3/Ethernet 105 Packet, IPv6 ver 802.3/Ethernet 106 Packet, IPv4 ver 802.1Q VLAN 107 Packet, IPv6 ver 802.1Q VLAN 108 Packet, IP with header cmpressin (ROHC) 109 Packet, IP with header cmpressin (ECRTP) 18

19 110 Packet, IP ver 802.3/Ethernet with header cmpressin (ROHC) 111 Packet, IP ver 802.3/Ethernet with header cmpressin (ECRTP) GPCS PROTOCOL_TYPE Encding The encding f the value field is that defined in a new an Internet Assigned Numbers Authrity (IANA) registry. <TBD: insert reference t registry here>. The prtcl type is defined as ne byte. Type Length Value Scpe [1445/146]. cst One byte prtcl number DSx-REQ, DSx-REP Fr IPv4, the value f the field specifies a matching value fr the IP Prtcl field. If this parameter is mitted, then the cmparisn f the IP header Prtcl field fr this entry is irrelevant. Fr IPv6 (IETF RFC 2460), this refers t next header entry in the last header f the IP header chain. If this parameter is mitted, then the cmparisn f the IP header Prtcl field fr this entry is irrelevant. Fr a cnnectin using Generic Packet CS, this TLV shall be used t indicate the prtcl carried ver the cnnectin when the MULTIPROTOCOL_ENABLE is disabled. Fr ther packet CS types, PROTOCOL_- TYPE is nt used MULTIPROTOCOL_ENABLE Encding This parameter is used t indicate whether r nt multiple upper layer prtcl data packets are allwed t be transprted ver the same service flwcnnectin when the Generic Packet Cnvergence sublayer (GPCS) is used. This parameter nly applies t GPCS. If enabled, the service flwcnnectin can carry multiple upper layer prtcls and the PROTOCOL_TYPE field must be prepended t each upper layer data packets fr the crrespnding CID. See sectin fr the GPCS PDU frmat. If disabled, a cnnectin must establish the single PROTOCOL_TYPE in use by exchanging the PROTOCOL_TYPE TLV in the DSx messages as specified in sectin Type Length Value Scpe [1445/146].cst : MULTIPROTOCOL_- ENABLE is disabled, default value. 1: MULTIPROTOCOL_- ENABLE is enabled, SDU is prepended with PROTOCOL_TYPE value described in sectin : Reserved fr future use DSx-REQ, DSx-REP 19