Universal Serial Bus
Communications Class Subclass Specifications for Network Control Model DevicesRevision 1.0April 30, 2009
CDC NCM Subclass Revision 1.0 Revision History
Please send comments or questions to: ncm@http://www.doczj.com/doc/109f22bcfd0a79563c1e7261.htmlRevision 1.0 CDC NCM Subclass
Copyright ? 2009, USB Implementers Forum, Inc.All rights reserved.
A LICENSE IS HEREBY GRANTED TO REPRODUCE THIS SPECIFICATION FOR INTERNAL USE ONLY. NO OTHERLICENSE, EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, IS GRANTED OR INTENDED HEREBY.
USB-IF AND THE AUTHORS OF THIS SPECIFICATION EXPRESSLY DISCLAIM ALL LIABILITY FOR INFRINGEMENTOF INTELLECTUAL PROPERTY RIGHTS, RELATING TO IMPLEMENTATION OF INFORMATION IN THIS
SPECIFICATION. USB-IF AND THE AUTHORS OF THIS SPECIFICATION ALSO DO NOT WARRANT OR REPRESENTTHAT SUCH IMPLEMENTATION(S) WILL NOT IN-FRINGE THE INTELLECTUAL PROPERTY RIGHTS OF OTHERS.THIS SPECIFICATION IS PROVIDED “AS IS” AND WITH NO WARRANTIES, EXPRESS OR IMPLIED, STATUTORY OROTHERWISE. ALL WARRANTIES ARE EXPRESSLY DISCLAIMED. NO WARRAN-TY OF MERCHANTABILITY, NOWARRANTY OF NON-INFRINGEMENT, NO WARRANTY OF FIT-NESS FOR ANY PARTICULAR PURPOSE, AND NOWARRANTY ARISING OUT OF ANY PROPOSAL, SPECIFICATION, OR SAMPLE.
IN NO EVENT WILL USB-IF OR USB-IF MEMBERS BE LIABLE TO ANOTHER FOR THE COST OF PROCURINGSUBSTITUTE GOODS OR SERVICES, LOST PROFITS, LOSS OF USE, LOSS OF DATA OR ANY INCIDENTAL,
CONSEQUENTIAL, INDIRECT, OR SPECIAL DAMAGES, WHETHER UNDER CONTRACT, TORT, WARRANTY, OROTHERWISE, ARISING IN ANY WAY OUT OF THE USE OF THIS SPECIFICATION, WHETHER OR NOT SUCH PARTYHAD ADVANCE NOTICE OF THE POSSI-BILITY OF SUCH DAMAGES.
All product names are trademarks, registered trademarks, or service marks of their respective owners.CDC NCM Subclass Revision 1.0Contributors
Bruce Balden BelcarraStuart Lynne BelcarraMorten Chr istiansen EricssonAlan Berkema Hewlett Pack ardJoel Silver man K-Mic roPaul E. Berg MCCIJoe Decuir MCCI, CSRPeter FitzRandolph MCCITerry Moor e MCCI
Dan Sternglass MCCIKen Taylor MotorolaDavid Willcox MotorolaKenji Oguma NECRichar d Petrie NokiaJanne Rand NokiaTero Soukko Nokia
Takashi N injouji NTT DoCoMoDale Self Sym bianJohn Turner Sym bianSaleem Mohammad SynopsisRevision 1.0 CDC NCM SubclassTable of Contents1Introduction (9)1.1Purpose (9)1.2Scope (9)
1.3Other USB Networking Specifications (9)1.4Editorial Notes (10)1.5Related Documents (10)1.6Terms and Abbreviations (11)2Overview (12)3Data Transport (14)3.1Overview (14)
3.2NCM Transfer Headers (16)3.2.1NTH for 16-bit NTB (NTH16) (16)3.2.2NTH for 32-bit NTB (NTH32) (17)3.3NCM Datagram Pointers (NDPs) (18)3.3.1NDP for 16-bit NTBs (NDP16) (18)3.3.2NDP for 32-bit NTBs (NDP32) (19)3.3.3Datagram Formatting (20)
3.3.4NCM Ethernet Frame Alignment (20)3.4NTB Maximum Sizes (21)3.5NTB format support (21)
3.6Ethernet frame Datagram Maximum Size (21)3.7Null NCM Datagram Pointer Entries (21)
4Class-Specific Codes (23)
4.1NCM Communications Interface Subclass Code (23)4.2NCM Communications Interface Protocol Code (23)4.3NCM Data Class Interface Protocol Codes (24)4.4NCM Functional Descriptor Code (24)5Descriptors (25)
5.1Standard USB Descriptor Definitions (25)
5.2NCM Communications Interface Descriptor Requirements (25)5.2.1NCM Functional Descriptor (26)
5.2.2Command Set Functional Descriptor (26)5.2.3Command Set Detail Functional Descriptor (26)5.3Data Interface Descriptor Requirements (27)6Communications Class Specific Messages (28)6.1Overview (28)
6.2Network Control Model Requests (28)6.2.1GetNtbParameters (30)6.2.2GetNetAddress (31)6.2.3SetNetAddress (31)6.2.4GetNtbFormat (31)6.2.5SetNtbFormat (32)
CDC NCM Subclass Revision 1.0 6.2.6GetNtbInputSize (32)6.2.7SetNtbInputSize (32)6.2.8GetMaxDatagramSize (33)6.2.9SetMaxDatagramSize (33)6.2.10GetCrcMode (33)6.2.11SetCrcMode (34)
6.3Network Control Model Notifications (35)7Operational Constraints (36)7.1Notification Sequencing (36)
7.2Using Alternate Settings to Reset an NCM Function (36)7.3Remote Wakeup and Network Traffic (37)7.3.1Remote Wakeup Rules for Link Suspend (37)7.3.2Remote Wakeup Rules for System Suspend (38)Revision 1.0 CDC NCM SubclassList of figures
Figure 2-1 - NCM Function Example (13)Figure 2-2 - Network Control Model (13)Figure 3-1 - NTB layout details (16 bit) (15)Figure 3-2 - NTB layout details (32 bit) (15)List of Tables
Table 3-1: Sixteen Bit NCM Transfer Header (NTH16) (16)Table 3-2: Thirty-two bit NCM Transfer Header (NTH32) (17)Table 3-3: Sixteen-bit NCM Datagram Pointer Table (NDP16) (18)Table 3-4: Thirty-two bit NCM Datagram Pointer Table (NDP32) (19)Table 3-5: NDP Datagram Formatting Codes (20)
Table 4-1 NCM Communications Interface Subclass Code (23)Table 4-2 NCM Communications Interface Protocol Code (23)Table 4-3 NCM Data Class Protocol Code (24)Table 4-4: NCM Functional Descriptor Code (24)
Table 5-1: NCM Communication Interface Descriptor Requirements (25)Table 5-2: NCM Functional Descriptor (26)Table 6-1: Networking Control Model Requests (28)
Table 6-2: Class-Specific Request Codes for Network Control Model subclass (29)Table 6-3: NTB Parameter Structure (30)
Table 6-4: Networking Control Model Notifications (35)
Table 6-5: Class-Specific Notification Codes for Networking Control Model subclass (35)Revision 1.0 CDC NCM Subclass1 Introduction1.1 Purpose
The Communications Class Network Control Model (NCM) Subclass is a protocol by which USB hosts and devices canefficiently exchange Ethernet frames. These Ethernet frames may convey IPv4 or IPv6 datagrams that are transported over acommunications network. NCM is intended to be used with high-speed network attachments such as HSPA and LTE dataservices.
This specification builds upon the USB Communications Device Class subclass specification for Ethernet Control Modeldevices [USBECM12], with improvements to support much higher data rates:Multiple Ethernet frames can be aggregated into single USB transfers.
In order to minimize overhead when processing the Ethernet frames within the USB device, NCM functions can specify theirpreferences for how Ethernet frames may be best placed withina USB transfer.1.2 Scope
This document specifies a new control and data plane for networking devices, as a subclass based on the Universal SerialBus Class Definitions for Communications Devices specification [USBCDC12]. It sup-ports Ethernet [IEEE802.3] and similarnetworking techniques.
This specification defines the following material applicable to NCM functions:The class-specific contents of standard descriptors.Additional class-specific descriptors.Required interface and endpoint structure.Class-specific commands.Class-specific notifications.
The format of data that is exchanged with the host.The required behavior.
Behavior that is required of all USB devices and hosts is defined by [USB30] and [WU SB10]. Behavior that is required of allCommunications devices is defined by [USBCDC12]. Some commands and notifica-tions are based on material defined in[USBECM12].
1.3 Other USB Networking Specifications
At time of writing, three other USB networking subclasses were defined:1.Ethernet Control Model (ECM) [USBECM12]2.Ethernet Emulation Model (EEM) [USBEEM10]CDC NCM Subclass Revision 1.0
3.ATM Networking Control Model [USBATM12]
ECM and NCM are both applicable to IEEE 802.3 type Ethernet networking functions that can carry IP traffic to an externalnetwork. ECM was designed for USB full speed devices, especially to support DOC-SIS 1.0 Cable Modems. Although ECMis functionally complete, it does not scale well in throughput or efficiency to higher USB speeds and higher network speeds.NCM draws on the experience gained from ECM implementations, and adjusts the data transfer protocol to make it
substantially more efficient. EEM is intended for use in communicating with devices, using Ethernet frames as the next layerof trans-port. It is not intended for use with routing or Internet connectivity devices, although this use is not pro-hibited.[USBATM12] is applicable to USB-connected devices like ADSL modems which expose ATM traffic di-rectly. Rather thantransporting Ethernet frames, [USBATM12] functions send and receive traffic that is broken up into ATM cells and encodedusing AAL-2, AAL-4 or AAL-5. Although some of the insights that led to the design of NCM came from experience with[USBATM12] implementations, the two specifi-cations are addressing substantially different target applications.1.4 Editorial Notes
In some cases material from [USBCDC12] or [USBECM12] is repeated for clarity. In such cases, [USBCDC12] or[USBECM12] shall be treated as the controlling document, unless a change is specifically indicated by this NCMspecification.
In this specification, the word ‘shall’ is used for mandatory requirements, the word ‘should’ is used to expressrecommendations and the word ‘may’ is used for options.1.5 Related Documents
[ECMA368] Ecma-368, High Rate Ultr a Wideband PHY and MAC Standar d, 2005
[IEC60027-2] IEC 60027-2, Second edition, 2000-11, Letter sym bols to be used in electr ical technology - Part 2: Telecommu-nications and electronics
[IEEE802.11] IEEE 802.11 Part 11: W ireless LAN Medium Access Control (MAC) and Phys ical Layer (PHY) Specifications,1999
[IEEE802.16] IEEE 802.16 Part 16: Air Interface for Fixed Br oadband W ireless Access Sys tems, 2004
[IEEE802.3] ISO/IEC 8802-3 (ANSI/IEEE Std 802.3): Infor mation technology — Local and metropolitan area networks— Part3: Carrier sense multiple acc ess with collision detect ion (CSMA/CD) access method and phys ical layer specifica-
tions, 1993
[USB20] Universal Ser ial Bus Specification, revision 2.0. http://www.doczj.com/doc/109f22bcfd0a79563c1e7261.html[USB30] Universal Ser ial Bus Specification, revision 3.0. http://www.doczj.com/doc/109f22bcfd0a79563c1e7261.html .Unless otherwise specified, any reference to [USB30] includes [USB20] by reference, especially when referring to full- andhigh-speed devices. [USBATM12] USB Subclass Specification for ATM C ontrol Model, Revision 1.2http://www.doczj.com/doc/109f22bcfd0a79563c1e7261.html
[USBCCS10] Universal Ser ial Bus Common Class Specification, revision 1.0.http://www.doczj.com/doc/109f22bcfd0a79563c1e7261.html
[USBCDC12] Universal Ser ial Bus Class Definitions for Communications Devices, Revision 1.2.
http://www.doczj.com/doc/109f22bcfd0a79563c1e7261.html . [USBECM12] USB Subclass Specification for Ethernet ControlModel, Revision 1.2 http://www.doczj.com/doc/109f22bcfd0a79563c1e7261.html[USBEEM10] USB Subclass Specification for Ethernet Emulation Model, Revision 1.0http://www.doczj.com/doc/109f22bcfd0a79563c1e7261.html
[USBWMC11] Universal Ser ial Bus Subclass Specification for Wireless Mobile Communications, Version 1.1.http://www.doczj.com/doc/109f22bcfd0a79563c1e7261.html[WUSB10] Wireless Universal Ser ial Bus Specification, version 1.0,http://www.doczj.com/doc/109f22bcfd0a79563c1e7261.html /w usbRevision 1.0 CDC NCM Subclass 1.6 Terms and AbbreviationsTerm Description
802.3 Second generation netw orking cabling and signaling, commonly known as Ethernet II.(See[IEEE802.3])
Communications Inter-face A USB interface that has bInterfaceC lass set to the class code defined for CommunicationsClass. (See [USBCDC12])
Composite Dev ice A device or per ipheral that exposes two or more funct ions, each such funct ion being associated w ithone or more USB Interfaces.
Data Interface A USB interface that has bInterfaceC lass set to the class code defined for Data Class. (See[USBCDC12])
Datagram A collect ion of bytes forming a single item of information, passed as a unit from source to destination. DescriptorData structure used to describe a USB device capability or character istic.
Dev ice A logical or phys ical entity that receives a device address during enumeration.
Ethernet frame Generic term r epresenting the various kinds of datagrams that may be exchanged over DIX or 802.3networks.
Function A collect ion of one or more interfaces in a USB device, w hich taken together present a specific capa-bility of thedevice to the host.
GiB Gigabinary Byt es: 230 bytes [IEC60027-2]KiB Kilobinary bytes, 1024 byt es [IEC60027-2]LAN Local Area N etwork, e.g. [IEEE802.3].NCM CommunicationsInterface
A Communications Interface with bInterfaceSubclass set to the code defined in Table 4-1.
NCM Data Interface A Data Interface that is identified as a subordinate interface in a UNION descriptor that is associated with
an NCM Communications Interface.
NDP NCM Datagram Pointer: NTB structure that delineates Datagrams (typically Ethernet frames) within an N TB, see Table3-3. Depending on the N TB for mat, an NDB may use 16-bit or 32-bit offsets. NDP Entry Data structure in an NDP, giving theoffset and the length of a single datagram. See section 3.3. NTB NCM Transfer Block: a data structure for efficient U SBencapsulation of one or more datagrams.
Each N TB is designed to be a single USB transfer. See Figur e 3-1 and Figure 3-2.
NTB Format NTBs have two formats. A “16 bit NTB” pr imarily uses fields that are 16 bits wide; therefore, such an NTB islimited to a maximum size of 64 KiB. A “32-bit N TB” pr imarily uses fields that are 32 bitswide; therefore, a 32-bit N TB may be as long as 4 GiB.
NTH NTB Header: a data structure at the front of each N TB, which provides the information needed tovalidate the N TB and begin decoding. Depending on the N TB format, this may be either a 16-bitNTH16 (Table 3-1) or a 32-bit N TH32 (Table 3-2).
Union A relationship among a collection of one or more interfaces that can be considered to form a func-tional unit.
WUSB Wireless USB, as defined by [WUSB10].CDC NCM Subclass Revision 1.02 Overview
This subclass specification includes specifications for USB-connected external data network adaptors that model IEEE 802family Layer 2 networking functionality.Devices of these subclasses shall conform to:USB Specification [USB30], or
Wireless USB Specification [WUSB10], andCommunications Device Class 1.2 [USBCDC12]
The principal advantage of using NCM lies in its method of transporting multiple datagrams inside sin-gle USB bulk transfers.In addition to reducing interrupt overhead, the NCM specification allows the sender of data to arrange the datagrams withinthe transfer so that the receiver need do minimal copying after receipt.
This specification defines two ways of encapsulating datagrams, one allowing transfers up to 64KiB (up to forty (40) 1514-byte [IEEE802.3] Ethernet frames), and another for transfers of up to 4GiB, supporting thereby both [USB20] High Speed and[USB30] SuperSpeed data rates.
Devices implementing the NCM function may be composite devices as described by [USBWMC11].
An NCM function is implemented by an NCM Communications Interface and an NCM Data Interface. The NCM
Communications Interface is used for configuring and managing the networking function. The NCM Data Interface is used fortransporting data, using the endpoints defined by that interface. General-ly, the NCM Communications Interface and the NCMData Interface are managed by a single driver on the USB host. The logical connections between host driver and NCMfunction are shown in Figure 2-1, and the control and data connections are shown schematically in Figure 2-2.Revision 1.0 CDC NCM SubclassHostSystem
Networking Device
Figure 2-1 - NCM Function Example
Figure 2-2 - Network Control Model
Although an NCM function may stay in an “always connected” state, some management requests may be required to properlyinitialize both the function and the host networking stack. There also may be occa-sional changes of function configuration orstate, e.g., adding multicast filters in response to changes in the host networking stack.CDC NCM Subclass Revision 1.03 Data Transport3.1 Overview
NCM allows device and host to efficiently transfer one or more Ethernet frames using a single USB trans-fer. The USBtransfer is formatted as a NCM Transfer Block (NTB).
Figure 3-1 and Figure 3-2 outline the structure of the NTB. Each NTB consists of several components.
It begins with an NCM Transfer Header (“NTH”). This identifies the transfer as an NTB, and provides basic informationabout the contents of the NTB to the receiver (3.3.3.1).
The NTH effectively points to the head of a list of NDP structures (NCM Datagram Pointers).Each NDP in turn points to one or more Ethernet frames encapsulated within the NTB (3.3.3.2).Finally, the NTB contains the Ethernet frames themselves (3.3.3.3).
Within any given NTB, the NTH always must be first; but the other items may occur in arbitrary order.
There are two kinds of NTB. NTBs that are shorter than 65,536 bytes in length can be represented as “six-teen bit NTBs”(NTB-16). NTBs of up to 4 GiB in size can be represented as “thirty-two bit NTBs” (NTB-32). The structures are abstractly thesame, but NTB-16 form primarily uses 16-bit fields. The two formats are shown in Figure 3-1 and Figure 3-2, respectively.Although two formats are defined, a function only uses one format or the other at a given time. The same format is used for INand OUT transfers. The host selects the format to be used.
NTBs cannot be of arbitrary size; functions normally advertise their upper limits to the host. NCM allows functions to havedifferent maximum NTB sizes for transmit and receive. The sender of an NTB may vary the size of NTBs as needed.Revision 1.0
CDC NCM Subclass L bytesRepeat if/as needed
Zero padding may be inserted here if convenient Required termination of headerend
Figure 3-1 - NTB layout details (16 bit)
L bytes
Zero padding may be inserted here ifconvenient Required termination of header(size must be 16+k*8, 32, 40, etc.start of xfr –
Figure 3-2 - NTB layout details (32 bit)CDC NCM Subclass Revision 1.03.2 NCM Transfer Headers3.2.1 NTH for 16-bit NTB (NTH16)A 16-bit NT
B must begin with an NTH16 structure, described in Table 3-1.Table 3-1: Sixteen Bit NCM Transfer Header (NTH16)
Revision 1.0 CDC NCM Subclass3.2.2 NTH for 32-bit NTB (NTH32)
The 32-bit form of the NTH is described in Table 3-2.Table 3-2: Thirty-two bit NCM Transfer Header (NTH32)
CDC NCM Subclass Revision 1.03.3 NCM Datagram Pointers (NDPs)
NCM Datagram Pointers (NDPs) describe the Ethernet datagrams that are embedded in an NDP. As with NTH structures,two forms are defined. One form (the NDP16) is used for 16-bit NTBs; a second form (the NDP32) is used for 32-bit NTBs.These forms are architecturally equivalent, but differ in that many fields are 16-bits wide in the NDP16, but are 32-bits in theNDP32.
3.3.1 NDP for 16-bit NTBs (NDP16)
The layout of the NDP16 is given in Table 3-3. It has the following overall structure: ?8 bytes of header information 1 or more NCM Datagram Pointer Entries (4 bytes per entry) A terminating zero NCM Datagram Pointer Entry (4 bytes).Table 3-3: Sixteen-bit NCM Datagram Pointer Table (NDP16)
Revision 1.0 CDC NCM Subclass3.3.2 NDP for 32-bit NTBs (NDP32)
The layout of the NDP32 is given in the Table 3-4. It has the following overall structure: ?16 bytes of header information 1 or more NCM Datagram Pointer Entries (8 bytes per entry) A terminating zero NCM Datagram Pointer Entry (8 bytes).Table 3-4: Thirty-two bit NCM Datagram Pointer Table (NDP32)
因篇幅问题不能全部显示，请点此查看更多更全内容