1550!] EC 880253 . 1993
`I-.l\'.‘-‘sllll'2El‘I Std 8fl‘2..’%. 19533 Flxlihnn
`
`l.()f'.r1.L A NI} llll-'.'l‘li("li’f}l.l'l'A.‘-I AREA .\’l:ITWI’.J!'il-Ch.
`
`OSI
`REFERENCE
`MODEL
`LAYERS
`
`LAN
`CSMA-‘CD
`LAYERS
`
`APPLICATION
`
`:
`
`WGHER LAYERS
`
`:
`
`'°"‘E3E“”‘T'°“
`
`LOGICAL com
`
`SESSION
`
`I: i ED”
`
`' E3
`I
`
`.
`
`.
`
`'
`
`DTE
`(AU|not
`
`ATTACHMENT UNIT INTERFACE
`MEDIUM ATTACHMENT UNIT
`MEDIUM DEPENDENT INTERFACE
`PHYSICAL MEDIUM ATTACHMENT
`
`Fig 1-]
`LAN Standard Relationship to the [S0 Open Systems Interconnection
`(OSI) Reference Model
`
`The architectural model is based on a set of interfaces that may be different from those emphasized in
`implementations. One critical aspect of the design, however, shall be addressed largely in terms of the
`implementation interfaces: compatibility.
`
`1.1.2.2 Two important compatibility interfaces are defined within what is architecturally the Physical
`Layer.
`
`(1) Medium-Dependelit Interface (MDI). To communicate in a compatible manner, all stations shall
`adhere rigidly to the exact specification of physical media signals defined in Section 8 (and beyond)
`in this standard, and to the procedures that define correct behavior of a station. The medium-inde-
`pendent aspects of the LLC sublayer and the MAC sublayer should not be taken as detracting from
`this point; communication by way of the ISO 8802-3 [lEEE 802.3] Local Area Network requires com-
`plete compatibility at the Physical Medium interface (that is, the coaxial cable interface).
`(2) Attachment Unit Interface (AUI). It is anticipated that most DTEs will be located some distance
`from their connection to the coaxial cable. A small amount of circuitry will exist in the Medium
`Attachment Unit [MAU) directly adjacent to the coaxial cable, while the majority of the hardware
`and all of the software will be placed within the DTE. The AUI is defined as a second compatibility
`interface. While conformance with this interface is not strictly necessary to ensure communication,
`it is highly recommended, since it allows maximum flexibility in intermixing M.AUs and DTEs. The
`AUI may be optional or not specified for some implementations ofthis standard that are expected to
`be connected directly to the medium and so do not use a separate MAU or its interconnecting AU1
`cable. The PLS and PMA are then part of a single unit, and no explicit AU] specification is required.
`
`1.1.3 Layer Interfaces. In the architectural model used here, the layers interact by way of well defined
`interfaces, providing services as specified in Sections 2 and 6. In general, the interface requirements are as
`follows.
`
`Aerohive - H
`
`Aerohive - Exhibit 1026
`0035
`
`

`
`CSl_‘.'l.lUC'l]
`
`ISO:"IEC 3302-3 : l993
`ANSIHEEE Std 302.3, 1993 Ed.itiocn
`
`(ll The interface between the MAC sublayer and the LLC sublayor includes facilities for transmitting
`and receiving frames. and provides per-operation status information for use by higher-layer error
`recovery procedures.
`(2) The interface between the MAC eublayer and the Physical Layer includes signals for framing (earn
`rier sense, transmit initiation) and contention resolution (collision detect], facilities for passing a
`pair ofserial bit streams ltraiismit, receive) between the two layers, and a wait function for timing.
`
`These interfaces are described more precisely in -1.3. Additional interfaces are necessary to allow higher
`level network management facilities to interact with these layers to perform operation, maintenance, and
`planning functions. Network management functions will be I.'l.l5C11ESEI2l. in Section 5.
`
`1.1.4 Application Areas. The applications environment for the Local Area Network is intended to be
`commercial and light industrial. Use of CSMAICD LANs in home or heavy industrial environments, while
`not precluded, is not considered within the scope of this standard.
`
`1.2 Notation
`
`1.2.1 State Diagram Conventions. The operation of a protocol can be described by subdividing the pro-
`tocol i.nto a number of interrelated functions. The operation ofthe functions can be described by state dia-
`grams. Each diagram represents the domain of a function and consists of a group of connected, mutually
`exclusive states. Only one state of a function is active at any given time (see Fig 1-2}.
`
`TEFIMS TU‘ ENTEFI
`5-FATE
`
`STATE NAME
`
`cME SSPAGE SENT‘:-
`
`it; . . ‘.1 [CU'NDlTl'UN]
`
`[ACT1Dr-JS TAKEN]
`
`TEHMS TU EXIT
`5-I-A-I-E
`
`l}
`
`condlllon. tor example. {If no_colIisJon}
`amion, for example. [reset F'|.5Iunc1ions]
`logical AND
`logical DFI
`Wait Time, lmplsrnentatlon dsponcisrit
`Delay Tlmooul
`Bsokoff '|':rnaou1
`unconditional iransilion
`
`o:
`Td
`Tb
`
`E
`
`+T
`
`UGT||1|||||l||||||
`
`Kay:
`
`Fig 1-2
`State Diagram Notation Example
`
`Each state that the function can assume is represented by a rectangle. These are divided into two pm-ts
`by a horizontal line. In the upper part the state is identified by a name in capital letters, The lower part
`contains the name of any ON signal that is generated by the fiinction. Actions are described by short
`phrases and enclosed in brackets.
`Pill permissible transitions between the states of a function are represented graphically by an-uwa
`between them. A transition that is global in nature (for exarnple, an exit ormdition from all states to the
`IDLE or RESET state) is indicated by an open arrow. Labels on transitions are qualifiers tl-lat must be ful-
`filled before the transition will be taken. The label UCT designates an unconditional transition, Qualifiers
`deflmibcd by short phrases are enclosed in parentheses.
`State transitions and sending and receiving of messages occur instantaneously. when a state is entered
`and the condition to leave that state is not immediately fulfilled, the state executes continuously, grinding
`the messages and executing the actions contained in the state in a continuous manner.
`
`33
`
`Aerohive - H
`
`Aerohive - Exhibit 1026
`0036
`
`

`
`TSUATIEC 3802-3: 1993
`ANSI.-VIEEE Std 302.3, 1993 Edition
`
`LOGALANIJ METROPOLI'|‘#iN AREA NETWORKS:
`
`Some devices described in this standard (e.g., repeaters) are allowed to have two or more ports. State
`diagrams capable of describing the operation of devices with an unspecified number of ports, required qual-
`ifier notation that allows testing for conditions at multiple ports. The notation used is a term that includes
`a description in parentheses of which ports must meet the term for the qualifier to he satisfied (e.g., ANY
`and ALL}. It is also necessary to provide for term-assignment statements that assign a name to a port that
`satisfies a qualifier. The following convention is used to describe a term-eeeignrnent statement that is asso-
`ciated with a transition:
`
`(1) The character '“‘:’° (colon) is a deiiiniter used to denote that a term assignment statement follows.
`(2) The character "«:=‘° flefi arrow) denotes assignment ofthc value following the arrow to the term pre-
`ceding the arrow.
`The state diagrams oontain the authoritative statement of the functions they depict; when apparent con-
`Elicts hetween descriptive text and state diagrams arise, the state diagrams are to take precedence. This
`does not override, however, any explicit description in the text that has no parallel in the state diagrams.
`The models presented by state diagrams are intended as the primary specifications of the functions to he
`provided. It is important to distinguish, however, between a model and a real implementation. The models
`are optimized for simplicity and clarity of presentation, while any realistic implementation may place
`heavier emphasis on efflciency and suitalJilit}' to :1 particular implementation technology. It is the func-
`tional behsvior of any unit that must match the standard, not its internal structure. The internal details of
`the model are useful only to the extent that they specify the external behavior clearly and precisely.
`
`1.2.2 Service Specification Method and Notation. The service of a layer or suhlayer is the set of
`capabilities that it offers to a user in the next higher isuhllayer. Abstract services are sp-eciiied here by
`describing the service primitives and parameters that characterize each service. This definition of service
`is independent of any ps.rticuls.r implementation (see Fig 1-3).
`
`N
`LHYEFI
`SEFIVICE USER
`
`N
`L.FI."I"EFi
`SERVICE USER
`
`LAYEFI N-1
`SEFNIGE PHDVIDEFI
`
`Fig 1-3
`Service Primitive Notation
`
`Specific implementations may also include provisions for interface interactions that have no direct, end.
`to-end effects. Examples of such local interactions include interface flow control, status requests and indi-
`cations, error noiificatioos, and layer management. Specific implementation details are omitted from this
`service specification both because they will dilfer from implementation to implementation and because
`they do not impact the peer-to-peer protocols.
`
`1.2.2.1 Classification of Service Primitives. Primitives are of two generic types:
`
`(1) REQUEST. The request primitive is passed from layer N to layer N-] to request-. that s ge]1ri|_',c he
`initiated.
`
`Aerohive - H
`
`Aerohive - Exhibit 1026
`0037
`
`

`
`CSMNCD
`
`ISITIEC 8802-3: 1993
`ANSLEEEE Std 802.3, 1993 Edition
`
`(2)
`
`INDICATION. The indication primitive is passed Erom layer N-1 to layer N to indicate an internal
`layer N—1 event that is significant to layer N. This event may be logically related to a remote service
`request, or may be caused by an event internal to layer 11-1.
`
`The service primitives are an abstraction of the fimctional specification and the uE.e1'-layer interaction.
`The abstract definition does not contain local detail of the useniprovider interaction. For instance, it does
`not indicate the local mechanism that allows a user to indicate that it is awaiting an incoming call. Each
`primitive has a set of zero or more parameters, representing data elements that shall be passed to qualify
`the functions invoked by the primitive. Parameters indicate information available in a usei-,"p1-ovider inter-
`action; in any particular interface, some parameters may he explicitly stated (even though not explicitly
`defined in the primitive) or implicitly associated with the service access point. Similarly, in any particular
`protocol specification, functions corresponding to a service primitive may be explicitly defined or implicitly
`available.
`
`1.2.3 Physical Layer and Media Notation. Users of this standard need to reference which
`implementation is being used or identified. Therefore, a means of identifying each implementation is
`by a simple, three-field, tyne notation that is explicitly stated at the beginning of each relevant section. In
`general, the Physical Layer type is specified by the fields:
`
`-cdata rate in Ml:v's::- flnedium type:-.~ <:maJcimum segment length (X 100 m)‘:-
`
`For example, the standard contains a 10 Mhls baseband specification identified as ‘TYPE 1DBASE5,”
`meaning a 10 l‘ldl:J."s baseband medium whose maximum segment length is 500 m. Each successive Physical
`Layer specification will state its own unique TYPE identifier along similar lines.
`
`1.2.4 Physical Layer Message Notation. Messages generated within the Physical Layer, cither
`within or between PLS and the MAU [that is, PMA circuitry), are designated by an italic type to designate
`either form of physical or logical message used to execute the physical layer signaling process (for example,
`inpnttjdle or rrutu._cuo£ico.'.'eJ.
`
`1.3 References
`
`[1] CISPR Publication 22 (1985), Limits and Methods of Measurement of Radio Interference Charactmis»
`tics of Information Technology Equipment?
`
`[2]
`
`[EC Publication 96-1, R.adio-frequency cables, Part 1: General requirements and measuring methodsll
`
`LEG Publication 96-IA, lat Supplement to Radio-fi'equcncy cables, Part 1.: Appendix Section 5.4, Terr
`[3]
`minated triaxial test method for transfer impedance up to 100 Ml-ls.
`
`H313 Publication 159-3 and -16, Radio-frequency connectors, Part B: Radio-frequency coaxial connec-
`['1]
`tors with inner diameter of outer conductor 6.5 mm (0.256 in] with bayonet ln::k—Characterisfic imped-
`ance 50 ohms {Type BNO]; Part 16: Rad.io—frequency coaxial connectors with irmer diameter of outer
`conductor 7 mm (0.275 in) with screw eoupling—Characte1'istic impedance 50 ohms (TE ohms) (Type N).
`
`[5]
`
`IEC Publication 330, Safety of electrically energised ofiice machines.
`
`[6]
`
`IEC Publication 435, Safety of data processing equipment.
`
`%ISP'R documents are available from the International Electroieohoical Commission, 3 rue file Vnmmbé, Case Peetelc 131, CH
`1211. Geneva 2|], 3wit::erlund.I'Suisse. CISPR do-cumenlzi are also available in the United States fium the Sales Department, American
`National Staudarcls Institute, 11 West 42nd Street, 13th Floor, NawYorl{_NY 10036, USA.
`SIEC Pfllllifliltiflfls are available from IEC Sales Department, Case Pnstsle 131, 3 rue dc Varembé, UH-12.11, Geneva 2:}, 5witzsr-
`landfiuissn. IEC publications are also available in the United States from the Sales Department, American National Standards Insti-
`|»I.1‘|‘«E, 11 West 42nd Street, 13th Floor, New York, NY H1036. USA.
`
`35
`
`Aerohive - l
`
`Aerohive - Exhibit 1026
`0038
`
`

`
`ISOHEC B802-3 : 1993
`ANSI.-'lEEE Std 802.3. 1993 Edition
`
`LOCAL AND l\«1F‘.'T‘m"IP(‘fl.TTAN AREA. NF"-'T‘WOF.l£9:
`
`IEC Publication B07-2, Rectangular connectors for frequencies below
`[7]
`3 MHZ, Part 2: Detail Specification for a range of connectors with round contacts—Fixed solder contact
`types.
`
`IEC Publication 950, Safety of Information Technology Equipment, Including Electrical Business
`[8]
`Equipment.
`
`[9]
`
`ISO 2382-9 : 1984, Data processing—Vocabulary—Part 09: Data communication.‘
`
`ISO 7498 : 1984, Information processing systems—open systems interconnection—Basic reference
`[10]
`model.
`
`[11] IEC Publication 60, High-voltage test techniques.
`
`[12] IEC Publication 68, Environmental testing.
`
`[13]
`
`[EC Publication 793-1, Optical fibres, Part 1: Generic specification.
`
`[14] IEC Publication 793-2, Optical fibres, Part 2: Product Specificationsfi
`
`[15] [EC Publication 794-1, Optical fibre cables, Part 1: Generic specification.
`
`[16] [EC Publication 794-2, Optical fibres cables, Part 2: Product specifications.
`
`[17] IEC Publication 825, Radiation safety of laser products, equipment classification, requirements, and
`user’s guide.
`
`[18] IEC Publication 874-1, Connectors for optical fibres and cables, Part 1: Generic specification.
`
`[19] IEC Publication 874-2, Connectors for optical fibres and cables, Part 2: Sectional specification for fibre
`optic connector type F-SMA.
`
`[20] ISO/IEC 7498-4 : 1989, Information processing systems—Open Systems Interconnection—Basic Ref-
`erence Model—Part 4: Management Framework.
`
`ISO 8877 : 1987, Information processing systems—Interface connector and contact assignments for
`[21]
`ISDN basic access interface located at reference points S and T.
`
`Local and national standards such as those supported by ANSI, EIA, IEEE, MIL, NFPA, and UL are not
`a formal part of the ISO/IEC 8802-3 standard. Reference to such local or national standards may be useful
`resource material and are identified by a bracketed number beginning with the letter A and located in
`Annex A.
`
`1.4 Definitions. The definitions used in this standard are consistent with ISO 2382-9215984 [9]. A more
`specific Part 25, pertaining to LAN systems, is in development.
`
`‘ISO publications are available from the ISO Central Secretariat, Case Postale 56, 1 rue de Varembé, CH—12 ll, Geneve 20, Switzer-
`land.-'Suisse. ISO publications are also available in the United States from the Sales Department, American National Standards Inst}.
`tute, 11 West 42nd Street, 13:}: Floor, New York, NY 10036, USA.
`
`5 Subsection 9.9 is to be read with the understanding that the following changes to IEC Publication 793-2 [14] have been requested.
`(1) Correction of the numerical aperture tolerance in Table III to d: 0.015,
`(2) Addition of another bandwidth category, of3_’ 150 MHz referred to 1 km, for the type Alb fiber in Table III.
`
`36
`
`Aerohive - H
`
`Aerohive - Exhibit 1026
`0039
`
`

`
`ISO.I"IEC B80-2-3 : 1993
`ANSI-"'IEEE Std 502.3. 1993 Edition
`
`2. MAC Serviee Specification
`
`2.1 Scope and Field of Application. This section specifies the services provided by the Media Access
`Control {MAC} sublsyer to the Logical Link Control (LLG) sublsyer for the ISO [IEEEI Local Area Network
`standard {see Fig 2-1]. The services are described in an abstract way and do not iniply any particular
`implementation, or any exposed interface. There is not necessarily a one-to-one correspondence between
`the primitives and the formal procedures and interfaces described in 4.2 and 4.3.
`
`OSI
`HEFEHENCE MODEL
`LAYEFIS
`
`LAN
`CSMAFCD
`LAYERS
`
`HPGH ER LAYERS
`
`LLC
`LOGICAL LINK CONTROL
`wwwarmm-mmasvvvw
`em mama
`
`MEDIA ACCESS CONTROL
`
`PL5
`PHYSICAL SIGNALING
`
`:
`
`I
`
`3
`
`-I———-——§—AuI
`
`ATTACHMENT UNIT INTEFIFACE
`MEDIUM ATFAGHMENT UNIT
`MEDIUM DEPENDENT INTEHFRCE
`PHYSICAL MEDIUM ATTAGHM ENT
`
`Fig 2-1
`Service Specification Relation to the LAN Model
`
`2.2 Overview of the Service
`
`2.2.1 General Description of Services Provided by the Layer. The services provided by the MAC
`suhlayer SHOW the local LLC sublsyezr E'.|I1lIit§"tl.') exchange LLC data units with peer LLC sublayer entities,
`'D]Jfi|J'flB1 S1-11.’II2|0l't may be provided fl)!‘ resetting the MAC sublsjrer entity to a known state.
`
`2.2.2 Model Used for the -Service Specification The model used in this service specification is identi.
`cal to that used in 1.2.
`
`2.2.3 Overview of Interactions
`
`MA_DATA,request
`MA_DATA.iJ1dicat1on
`
`2-2-4 Basie Services and Options. The Da'l.d._DATA.request and MA_DATA,ind1'cat1un aervioe primj-
`1-‘iv-35 tieficrihed in this section are considered mandatory.
`
`3'.7
`
`Aerohive - H
`
`Aerohive - Exhibit 1026
`0040
`
`

`
`ISOIIEC S302-3 : 1993
`fi.NSL"'IEEE Std 802.3, 1993 Edition
`
`2.3 Detailed Service Specification
`
`2.3.1 MA_DATA.:-equest
`
`2.3.1.1 Function. This primitive defines the transfer of data from a local LLC sublayer entity to a sin-
`gle peer LLC entity or multiple peer LLC entities in the case of group addresses.
`
`2.3.1.2 Semantics of the Service Primitive. The semantics of the primitive are as follows:
`
`(d
`
`estination_address,
`m_sdu,
`service,class
`l
`
`MA_DATA .request
`
`The destination_address parameter may specify either an individual or a group MAC entity address. It
`must contain sufficient information to create the DA field that is appended to the frame by the local MAC
`sublayer entity and any physical information. The m_sdu parameter specifies the MAC service data unit to
`be transmitted by the MAC sublayer entity. There is sufficient information associated with m_sdu for the
`MAC sublayer entity to determine the length of the data unit. The service_class parameter indicates a
`quality of service requested by LLC or higher layer (see 2.3.1.5).
`
`2.3.1.3 Wlien Generated. This primitive is generated by the LLC sublayer entity whenever data shall
`be transferred to a peer LLC entity or entities. This can be in response to a request from higher protocol
`layers or from data generated internally to the LLC sublayer, such as required by Type 2 service.
`
`2.3.1.4 Effect of Receipt. The receipt of this primitive will cause the MAC entity to append all MAC
`specific fields, including DA, SA, and any fields that are unique to the particular media access method, and
`pass the properly formed frame to the lower protocol layers for transfer to the peer MAC sublayer entity or
`entities.
`
`2.3.1.5 Additional Comments. The CSMA/CD MAC protocol provides a single quality of service
`regardless of the service_class requested.
`
`2.3.2 MA_DATA.indication
`
`2.3.2.1 Function. This primitive defines the transfer of data from the MAC sublayer entity to the LLC
`sublayer entity or entities in the case of group addresses.
`
`2.3.2.2 Semantics of the Service Primitive. The semantics of the primitive are as follows:
`
`MA_DATA.indication (
`destination,address,
`source__address,
`m_sdu,
`reception__status
`)
`
`The destination_address parameter may be either an individual or a group address as specified by the
`DA field of the incoming frame. The source_address parameter is an individual address as specified by the
`SA field of the incoming frame. The m_sdu parameter specifies the MAC service data unit as received by
`the local MAC entity. The reception_status parameter is used to pass status information to the peer LLC
`sublayer entity.
`
`2.3.2.3 When Generated. The M.A_DATA.indication is passed from the MAC sublayer entity to the
`LLC sublayer entity or entities to indicate the arrival of a frame to the local MAC sublayer entity. Such
`
`38
`
`Aerohive - l
`
`Aerohive - Exhibit 1026
`0041
`
`

`
`Tu r._‘;—.-"'_.'.‘1 .:ni_'.'
`;_I :uJ|||'
`.1.--J.'n.:1--_»t]w 1'-'-1| H.-\|"'
`
`'..'_r"n .11’:-'..'._']'i|'.
`1‘.'
`'r=r'.I'_1'.'
`
`‘I-r1::I -'.. 1- x-
`
`.'-I I‘.
`
`'.\'l'."'1E}'_E'-.
`
`I ]'I'--r nhli 1211-..'
`
`Ilr--i1JJ'I.iT'I-'-1‘
`
`;uI1r]1'1"'»:;.
`
`'..:..'L'3_-I I-‘Afr-{'1 nf H.r-rt:-ipl. 1111- -.-T1-['L'T+1.'1"-'iI'.1'. n‘ t.':J—'
`
`::."‘.1'n'.‘_1"\-'1.-h_L'
`
`':}1r LLI '
`
`.~11hl.1_'.'.-r
`
`:-: 1:.r1;';;'-4:r._:fir-:1"
`
`2.11.2.5 A.ddi1im-mlC'L>mm1:1H.5.1!’t.hn-14::-:1! ‘.'«l.v'U' 5'11-!.1_'y'-:_-r '-_*nt'.tj.‘J-.1I1r'.-J-1|T11uf-.~J}:\.'t11L-1ia:re1.11'nI1I'::'!n_.1.i
`nin-m 5.-.nr.u1:u!r.-ru'|':1n M.-1:. 13!.-'!.'1'.-‘L.h.-n.|ur-.1,1&1?:mli:'.ItL:1t:L;.1:':mL;‘iV'E' WH1 ..=].-141'-‘I-o'J.:'tIJiw1'. h§.'H'.L' 3'-1.-"J." L‘I1Lii_\'
`[4I'J'|l'I.1Ii'il| 1'_.Lt_‘»_:11r|1_~.'
`‘Tin-41'1J]! ILi1:I§..IJI‘.'|: uT1:.rm-1:---1
`1-
`-:1" flu 5.{P-f.‘- 2‘-'J".:L-._'-‘L-H11-u‘ ".--~ n11.I~~t1- '1n'.»i1:r- F11ru“t'Iun-
`.1!-.'~. wit}-.-n :'r1+- M.-\I’.' -=u|:]:aw-r -:1'T-1.1:;
`tlupl--as 1-h=-1-::I.L--":.~»Tm+ I11'1.':1e '2-.1‘-'~'+-"
`|-:»'»"'- firm" <-1.;-.1n1:-|+.=.
`:I'1 t"r'.in1!-H
`:_r,-.11.-.m,'_t_-_-:'.
`-'_n
`'_}-.c-
`In-u-,Ld;-.-|..—'.
`.u'I:iru,«.- will nnrnkc .\'l.-“.
`|.PA'l'.'~'1..ind.l£:a'.ir:!:
`.1’. H].
`:+.'.'.*iI:.".M 1:1
`thn Hr.‘-’r.'-W11".-\
`_1::_'11I1 nu: tL1- .-4‘-.31‘-:r1 rh-.11 _|;:-rLrr-.1tr.1 7.11:1 I|‘I]_lH.‘H1-
`
`Aerohive - H
`
`Aerohive - Exhibit 1026
`0042
`
`

`
`IE-H'.lf.|'P.{‘. sun-2.3: 199:5
`;ui.*iI.u"lEi-.‘2F'. am Mon 1 ram Edilang
`
`3. Media Access Con lrul Frame Structure
`
`3.! Overview. This section eiefinee in detail the Frame structure for data curnrn-.intc.1l.iu:1 Ilyatema us-"rI1g
`local area network MAC pr-acedures. ll: define! the relative p-usitilma nfthe variuun cnmpnnenta M the MAC
`frame. it dllnes the method fur repmsxunling utntinn addresses. It defines a partitiur. of the nddreaa space
`Lntu individual (single atatinn) and group I[mull;i-cunt. ur multistetiunl addressee. i-Ind ll1l.¢Hl.|lu|hr administered
`and globally administered addressee.
`
`£11.! MAC Frame Format. Figure 3-! Iil1DWIl the eight fields of a frame: the preamble, Start Frame
`Dellmil-er ISFD), the addresses nfthe l'rI1mn.-1'5 Buurw and deltlnafifin. fl lflngth field ‘Lu indirlnte the length of
`Lhu fculluwhig field ccmtaming the LLC data In he lrnnmaiued, 5 field that contains pmirling if rpquin-_Id_ and
`the frame died: sequence field mnmirdng .1.
`t'}'lZl|l‘ redundancy cheek value to detect error: in received
`firemen (If these m'.g|:|t fields, all are of fined state except the LLC data and FAD fields, wI:1jd1 may cIm§a.i::1
`any integer number ufo-cteta between the mjrumum and maximum values deter-rm'ned by I‘,l1¢' apetific
`implementation ufthe L-'S1h1AfCD Media Amen mu-rhtmmr: See -t.-: for paJ'ti1'.‘.1.lnri:r1plornonInI1una
`
`F C|Cl'El‘i
`
`l'UCTEl
`
`2 53 3 ocfifi
`
`l3F§'l|N.hT|L'|l'l
`3-DUHEIJ-Ll
`
`2 an 5 oc:rET6
`
`5°””cE
`IQDHE55
`
`i an
`
`1 arms ‘fun-II Izrrl.-1:-L
`
`L» Lulmngj
`
`Hl'1'fl- |n'1'1'H1H|
`FRAME TIUIHEMITFED
`l—- — LEFT-‘ID-Hlfflii fr»
`
`I: D
`
`Fig 3»!
`MAI! Frame Format
`
`The mlmmurn and EIIEIIIDIIUTI frame sue lil'l1l'|'-I in -I.-I refer to that portion of me frame fr-um the dest.L1a—
`tmn nddreu field through the frame check Ia-qur-1:ne field. hlriustve.
`Relative to Fig 3-1. the nctetsofa frame are ta-mu:m.1tted fmm tupte but1.um.and the hit» ufrach octet are
`transmitted Emu] left In right.
`
`3.2 Element: at the MAC Frame
`
`3.5.1 Preamble Field. The preamble Iluld is n 1'-uctut field that is used In: nil-nw the l"J.S oircuiltry to
`ranch itu Htn.-udy-n1.at.e iaynnhronizatiun with Lhn re-eL-[wad fi-eme timing (see -1.2.5}.
`
`11
`
`Aerohive - H
`
`Aerohive - Exhibit 1026
`0043
`
`

`
`130.-"l_|1'.C B8023 : 1993
`ANBL’lEEE Std B|ZI2.B.. 1993 Edition
`
`L.(J[_‘.AL AND METRDPUJ.-[TAN fir’; l‘H"E'l"i'~’O%:
`
`3.2.2 Start Frame Delimiter ISFD} Field. The SFD field 1'9 the Sequence 1D1{l1D11. It im1nediatelyt'ol—
`lows the preamble pattern. and indicates the start ofa fi'ame.
`
`3.2.3 Address Fields. Each MAC frame shall contain two address fields: the Destination Address field
`and the Source Address field, in that order. The D-2Eti_naliiIJI1 A-ddresfi field shall speeifir the destination
`addresses-(s) for which the frame is intended. The Source Address field shall identify the station from which
`the frame was initiated. The representation of each address field shall he as follows (see Fig 3-2):
`
`(1) Each address field shall contain either 16 hits or 48 hits. However, at any given time, the Source and
`Destination Address sine shall he the same for all stations on a particular local area network,
`The support of 16 or 43 bit address length for Source and Deslzination Address shall be loll to the
`manufacturer as an implementation decision. There ‘is no requirement that manufacturers support
`both sizes.
`The fixst bit (LS3) shall be used in the Destination Address field as an address type designation bit
`to identify the Destination Address either as an individual or as a group address. in the Source
`Address field, the first hit is reserved and set to Cl. If this hit is '3, it shall indicate that the address
`field contains an individual address. Lfthis bit is 1, it shall indicate that the address field eontains a
`group address that identifies none. one or mare, 01' all Of the Etfliififlfl connected to the lncal area
`network.
`
`For 48 bit addresses, the second I:-it shallbe used to di51t1'ngl.u'Eh between locally or globally adrni.nis-
`tcred addresses. For globally adnrinistered (or U, universal} addresses, the hit is set to CI. If an
`address is to be assigned locall3,r_ this bit shall be set to 1. Note that for the broadcast address, this
`bit is also a 1.
`Each octet of each address field shall be transmitted least significant hit fir:-11..
`
`45 BIT -RDDHE55 FCIFIMAT
`
`no
`
`U/L
`
`45 an AJDRESS
`
`16 BIT ADDRESS FORMAT
`,__._
`
`13:;
`
`1:. an anoerss
`
`D
`1
`|'J
`I_
`
`|N|II|l-a"||JUJl\L ADDRESS
`GRCIUP ADDRESS
`GLCIBlI.|,J.,"r' ADMINIEFERED IIDIJRESS
`LOCALLY .a\DM|NISTERE|I| P-E|DF€E‘S.‘_i
`
`15?.U L
`_fL
`
`Fig 5-2
`Address Field Format
`
`3.2.3.1 Address Dve.sig'rI.atien. AMAC suhlayer address is of one eftwo types:
`
`Individual Address. The address associated with a par'|:ic1J.lat' Station on the network.
`(1)
`{2} Group Address. A rnultidestinatifln addbefis. 355-EIC'l-flteiil with 0116 I11‘ more stations on a given net-
`work. There are two kinds of multicast address:
`
`Ila) Muliicast-Group Address. An address associated by highr.-r—level convention with a group of log-
`ically related stations.
`[bl Broadcast Address. A distinguished, predefined roultieast address that always denotes the set.
`of all stations on a given local area network.
`
`All 1’s in the Destination Address field (for 15 or 43 bit address size LANs) shall be predefined to be the
`Broadcast address. This group shall be predefined for Each communication medium to consist of s11 stations
`
`42
`
`Aerohive - l
`
`Aerohive - Exhibit 1026
`0044
`
`

`
`CSMAJCD
`
`ISOJJEJC 3302-.’-l : 1998
`ANSDLEEE Std 302.3, 1539.3 Edition
`
`actively connected to that medium; it shall be used to broadcast to all the active stations on that medium.
`All stations shall be able to recognize the Broadcast address. It is not necessary that a station be capable of
`generating the Broadcast address.
`The address space shall also be partitioned into locally administered and globally administered
`addresses. The nature of a bo-dy and the procedures by which it administers these global (U) addresses is
`beyond the scope of this standard}?
`
`3.2.4 Destination Address Field. The Destination Address field specifies the station(s}I for which the
`frame is intended. It may be an i11di1.-idual or multicast (including broadcast) address.
`
`3.2.5 Source Address Field. The Source Address field specifies the station sending the frame. The
`Source Address field is not interpreted by the CSMAICD MAC sublaycr.
`
`3.2.6 Length Field. The length field is a 2-octet field whose valuef indicates the number of LLC data
`octets in the data field. If the value is less than the minimum required for proper operation of the protocol,
`a PAD field {a sequence of octets) will be added at the end of the data field but prior to the F05 field, speci-
`fied below. The procedure that determines the size ofthe pad field is specified in 4.2.8. The length field is
`transmitted and received with the high order octet first.
`
`3.2.7 Data and PAD Fields. The data field contains a sequence of n octets. Full data transparency is
`provided in the sense that any arbitrary sequence of octet values may appear in the data. field up to a max-
`imum number specified by the implementation of this standard that is used. A minimum frame size is
`required for correct CSMAICD protocol operation and is specified by the particular implementation of the
`standard. If necessary, the data field is extended by appending extra bits (that is, a pad} in units of octets
`after the LLC data field but prior to calculating and appending the FCS. The size ofthe pad, if any, is deter-
`mined by the size of the data field supplied by LLC and the minimum frame size and address size parame-
`ters of the particular implementation. The maximum size of the data field is determined by the maximum
`frame size and address size parameters of the parti-::l:I.lar implementation.
`The length of PAD field required for LLC dat that is n octets long is max (0, rnin_F'ra.meSizc — {B x n + 2
`‘:6 addressSize + 43)} bits. The maximum possible size ofthe LLC data field is maxFrameSize -112 x address-
`Sizc + 4Eilr"3 octets. See 4.4 for a discussion ofimplernentation parameters; see 4.2.3.3 for a discussion ofthe
`IninFrameSize.
`
`3-2.8 F1:'alIle Cheek Sequence Field. A cyclic redundancy check (CRO) is used by the transmit and
`receive algorithms to generate a CRC value for the FCS field. The frame check sequence (FCS) field con-
`tains a 4-octet (32-bit) cyclic redundancy check (CRO) value, ‘This value is I,‘.l'!I]]1p'|Jt|;:d as a function of the
`eontents of the source address, destination address, length, LLC data and pad (that is, all fields except the
`preamble, SFD, and FCS]. The encoding is defined by the following generating polynomial,
`
`G{x):x-ii-2+IH5+xll.'i+123+115+x12_I_x'I1+x_lI|:|+x3+x7+x5+x4i-+x2+x+ 1
`
`Mathematically, the CRC value corresponding to a given frame is defined by the following procedure;
`
`ill The first 32 bits of the frame are complemented.
`(2) The n hits of the frame are then considered to be the coetficients of a polynomial M(:u:)ofdcg1-cc 11-1.
`(The first bit of the Destination Address field corresponds to the sin“ tenn and the last bit of the
`data field corresponds to the 3;“ term.)
`i3} Mix} is multiplied by 132 and divided by Gina), producing a remainder Rixj of degree <31,
`(‘ii The co-efficients of Rixl are considered to be a 32-bit sequence.
`(5) The bit sequence is complemented and the result is the CBC.
`
`“For information on how to use M.AG addressw, see IEEE Std 302-1990, Overview and an-.hiLauI:ure.'1'a apply fa: an 01-ggni;g.|_i¢.n_
`ally Unique Idrmtifier ihr building .'-1 fi'iAL". address, contact the Registration fluthorjlgyl IEEE. Standards ]Japfl_r1_|11gn[_'
`'P_(}_ Egg 1.3.31,
`-145 Hoes Lane, i‘iseaI.awa3.g NJ 03355-1331, USA‘, [903] 5523313,‘ [fix {QUE} 552-1-51"].
`_
`'3 Pfllllilltfil Wil-l‘-1 El length field value greater than those specified in 4.4.2 maybe ignored. discarded, or used in a private manner. ".['he
`use ofauch packetais beyond the scope ufthia standard.
`
`Aerohive - H
`
`Aerohive - Exhibit 1026
`0045
`
`

`
`ISDHEC EB-[I2-3 : 1993
`ANSI.-"JIEEE Std 302.3, 1993 Edition
`
`LUCALAND METROPOLITAN AREA NETWCIRKS;
`
`The 32 hits ofthe URC value are placed in the frame cheek sequence field eo that the 1:31 term is the left
`meet bit of the firet. octet, end the 1"‘ term is the right most bit ofthe lest octet, {The bite of the CRC are
`thus transmitted in the order 1:31, 130. .
`.
`. , X1. 39.} See reference [A18].
`
`3.3 Order of Bit Transmission. Each octet of the_MAC frame. with the exception of the FCS, is
`transmitted low-order bit iirst.
`
`3.4 Invalid MAC F1-nine. An imrelid MAC frame ehell be defined as one that meets et least one of the
`
`following conditions:
`
`(1) The frame length is inconsistent with the length field.
`[2]
`It is: not en integral number of octets in length.
`(3) The bits of the incoming frame (exelueive of the FCS field itself) do not generate a CEO value -identi-
`eel to the one received.
`
`The contents of inval