802.1q/p and NDIS 5.1 Intermediate driver

I'd like to be sure if this assumption is correct:
NIC driver supports VLAN and there is installed NDIS 5.1 IM driver.
For 802.1Q/p frame there is added a 32-bit field between the source MAC
address and the Ethernet Type.
When receiving packet is indicated in IM driver and consequently is called
ProtocolReceive(),
Is this 32-bit field always removed from packet when reaching
ProtocolReceive() ?
(Has ethernet frame in IM driver always 14-byte header in format:
DestMAC,SrcMAC,EthType followed by next protocol header)
?

Thanks !
Peter

> Is this 32-bit field always removed from packet when reaching
> ProtocolReceive() ?

No.

--
Maxim S. Shatskih
Windows DDK MVP

http://www.storagecraft.com

Thanks for the answer Maxim.
But I am a bit confused with this paragraph in DDK doc:

"In order to support 802.1Q packet information, a miniport driver must be
implemented to mark packets with 802.1Q information and to remove such
marking from packets. A miniport driver that supports 802.1Q packet
information must also be able to specify such support. The following topics
describe how to implement 802.1Q support"

By this paragraph, it seems that 802.1Q/p 32-bit field exist only in NIC
driver and it is removed when passed to upper IM driver and when packet is
sent, 32-bit field is added in NIC driver.
And you wrote that 32-bit field is still present in PtReceive() in IM driver.

Am I understanding this DDK doc paragraph wrong ?

Peter

"Peter" wrote:

> I'd like to be sure if this assumption is correct:
> NIC driver supports VLAN and there is installed NDIS 5.1 IM driver.
> For 802.1Q/p frame there is added a 32-bit field between the source MAC
> address and the Ethernet Type.
> When receiving packet is indicated in IM driver and consequently is called
> ProtocolReceive(),
> Is this 32-bit field always removed from packet when reaching
> ProtocolReceive() ?
> (Has ethernet frame in IM driver always 14-byte header in format:
> DestMAC,SrcMAC,EthType followed by next protocol header)
> ?
>
> Thanks !
> Peter

If the NIC adapter driver (miniport) supports the header tags by itself, then no other software components will ever see them.

But, if the support is in the IM driver, then it is visible to the software.

--
Maxim S. Shatskih
Windows DDK MVP

http://www.storagecraft.com

"Peter" <> wrote in message news:A716F9F3-61A4-43BE-9022-...
> Thanks for the answer Maxim.
> But I am a bit confused with this paragraph in DDK doc:
>
> "In order to support 802.1Q packet information, a miniport driver must be
> implemented to mark packets with 802.1Q information and to remove such
> marking from packets. A miniport driver that supports 802.1Q packet
> information must also be able to specify such support. The following topics
> describe how to implement 802.1Q support"
>
> By this paragraph, it seems that 802.1Q/p 32-bit field exist only in NIC
> driver and it is removed when passed to upper IM driver and when packet is
> sent, 32-bit field is added in NIC driver.
> And you wrote that 32-bit field is still present in PtReceive() in IM driver.
>
> Am I understanding this DDK doc paragraph wrong ?
>
> Peter
>
> "Peter" wrote:
>
>> I'd like to be sure if this assumption is correct:
>> NIC driver supports VLAN and there is installed NDIS 5.1 IM driver.
>> For 802.1Q/p frame there is added a 32-bit field between the source MAC
>> address and the Ethernet Type.
>> When receiving packet is indicated in IM driver and consequently is called
>> ProtocolReceive(),
>> Is this 32-bit field always removed from packet when reaching
>> ProtocolReceive() ?
>> (Has ethernet frame in IM driver always 14-byte header in format:
>> DestMAC,SrcMAC,EthType followed by next protocol header)
>> ?
>>
>> Thanks !
>> Peter

> If the NIC adapter driver (miniport) supports the header tags by
itself, then no other software components will ever see them.

In this case,
does it mean that if 802.1Q/p tagged frame is received through NIC adapter
driver, then in above IM driver's PtReceive() is present classic 14-byte
Ethernet header without 802.1Q/p 32-bit field ?

>
> But, if the support is in the IM driver, then it is visible to the software.
>
So if NIC adapter driver does not support 802.1Q/p,
and 802.1Q/p tagged packet is received, then in above IM driver's
PtReceive() is present 18-byte Ethernet Header with 802.1Q/p 32-bit field ?

Peter

> driver, then in above IM driver's PtReceive() is present classic 14-byte
> Ethernet header without 802.1Q/p 32-bit field ?

Yes.

> and 802.1Q/p tagged packet is received, then in above IM driver's
> PtReceive() is present 18-byte Ethernet Header with 802.1Q/p 32-bit field ?

Yes.

--
Maxim S. Shatskih
Windows DDK MVP

http://www.storagecraft.com

Support of .1Q/p by a miniport means that the miniport will
accept the Q/p data in out-of-band info of transmit packets,
and will insert this data in the out-of-band info of received packets.
Whether or not this data will be inserted or removed in
the packets, depends on the physical medium -
is it a real ethernet, or something else.

Of course, the best situation is when both miniport and protocols
understand both inband P/Q tags and OOB info.
Otherwise, one side must adapt to another.
If you have a real ethernet and your hardware does not help with
addind/removing the tags, don't declare support for P/Q and let
protocols deal with raw L2 packets.
But, if this breaks some silly <del><del> naïve IM,
have to remove the tag.

-- pa


"Peter" <> wrote in message
news:A716F9F3-61A4-43BE-9022-...
> Thanks for the answer Maxim.
> But I am a bit confused with this paragraph in DDK doc:
>
> "In order to support 802.1Q packet information, a miniport driver must be
> implemented to mark packets with 802.1Q information and to remove such
> marking from packets. A miniport driver that supports 802.1Q packet
> information must also be able to specify such support. The following
> topics
> describe how to implement 802.1Q support"
>
> By this paragraph, it seems that 802.1Q/p 32-bit field exist only in NIC
> driver and it is removed when passed to upper IM driver and when packet is
> sent, 32-bit field is added in NIC driver.
> And you wrote that 32-bit field is still present in PtReceive() in IM
> driver.
>
> Am I understanding this DDK doc paragraph wrong ?
>
> Peter
>
> "Peter" wrote:
>
>> I'd like to be sure if this assumption is correct:
>> NIC driver supports VLAN and there is installed NDIS 5.1 IM driver.
>> For 802.1Q/p frame there is added a 32-bit field between the source MAC
>> address and the Ethernet Type.
>> When receiving packet is indicated in IM driver and consequently is
>> called
>> ProtocolReceive(),
>> Is this 32-bit field always removed from packet when reaching
>> ProtocolReceive() ?
>> (Has ethernet frame in IM driver always 14-byte header in format:
>> DestMAC,SrcMAC,EthType followed by next protocol header)
>> ?
>>
>> Thanks !
>> Peter

Thanks Pavel for the answer.

One more question relating to 802.1Q/p and your explanation.
What about situation when NIC miniport driver has enabled 802.1Q/p support,
and "QoS Packet Scheduler" is also installed and enabled and priority packet
tagged with 802.1Q/p 32-bit field is received.
Which driver does bandwidth management in this case ?

Peter


"Pavel A." wrote:

> Support of .1Q/p by a miniport means that the miniport will
> accept the Q/p data in out-of-band info of transmit packets,
> and will insert this data in the out-of-band info of received packets.
> Whether or not this data will be inserted or removed in
> the packets, depends on the physical medium -
> is it a real ethernet, or something else.
>
> Of course, the best situation is when both miniport and protocols
> understand both inband P/Q tags and OOB info.
> Otherwise, one side must adapt to another.
> If you have a real ethernet and your hardware does not help with
> addind/removing the tags, don't declare support for P/Q and let
> protocols deal with raw L2 packets.
> But, if this breaks some silly <del><del> naïve IM,
> have to remove the tag.
>
> -- pa
>
>
> "Peter" <> wrote in message
> news:A716F9F3-61A4-43BE-9022-...
> > Thanks for the answer Maxim.
> > But I am a bit confused with this paragraph in DDK doc:
> >
> > "In order to support 802.1Q packet information, a miniport driver must be
> > implemented to mark packets with 802.1Q information and to remove such
> > marking from packets. A miniport driver that supports 802.1Q packet
> > information must also be able to specify such support. The following
> > topics
> > describe how to implement 802.1Q support"
> >
> > By this paragraph, it seems that 802.1Q/p 32-bit field exist only in NIC
> > driver and it is removed when passed to upper IM driver and when packet is
> > sent, 32-bit field is added in NIC driver.
> > And you wrote that 32-bit field is still present in PtReceive() in IM
> > driver.
> >
> > Am I understanding this DDK doc paragraph wrong ?
> >
> > Peter
> >
> > "Peter" wrote:
> >
> >> I'd like to be sure if this assumption is correct:
> >> NIC driver supports VLAN and there is installed NDIS 5.1 IM driver.
> >> For 802.1Q/p frame there is added a 32-bit field between the source MAC
> >> address and the Ethernet Type.
> >> When receiving packet is indicated in IM driver and consequently is
> >> called
> >> ProtocolReceive(),
> >> Is this 32-bit field always removed from packet when reaching
> >> ProtocolReceive() ?
> >> (Has ethernet frame in IM driver always 14-byte header in format:
> >> DestMAC,SrcMAC,EthType followed by next protocol header)
> >> ?
> >>
> >> Thanks !
> >> Peter
>
>

Peter wrote:
> Thanks Pavel for the answer.
>
> One more question relating to 802.1Q/p and your explanation.
> What about situation when NIC miniport driver has enabled 802.1Q/p support,
> and "QoS Packet Scheduler" is also installed and enabled and priority packet
> tagged with 802.1Q/p 32-bit field is received.
> Which driver does bandwidth management in this case ?
>
> Peter

If I remember correctly, the Psched IM does bandwidth management
and implements the stream queues for Traffic Control,
and it works with both types of L2 miniports - with or without P/q support.
The problem with bandwidth management in legacy (NDIS 5.x) miniports
is that Windows isn't aware of it, and psched is not documented well enough.

-- pa

> "Pavel A." wrote:
>
>> Support of .1Q/p by a miniport means that the miniport will
>> accept the Q/p data in out-of-band info of transmit packets,
>> and will insert this data in the out-of-band info of received packets.
>> Whether or not this data will be inserted or removed in
>> the packets, depends on the physical medium -
>> is it a real ethernet, or something else.
>>
>> Of course, the best situation is when both miniport and protocols
>> understand both inband P/Q tags and OOB info.
>> Otherwise, one side must adapt to another.
>> If you have a real ethernet and your hardware does not help with
>> addind/removing the tags, don't declare support for P/Q and let
>> protocols deal with raw L2 packets.
>> But, if this breaks some silly <del><del> naïve IM,
>> have to remove the tag.
>>
>> -- pa
>>
>>
>> "Peter" <> wrote in message
>> news:A716F9F3-61A4-43BE-9022-...
>>> Thanks for the answer Maxim.
>>> But I am a bit confused with this paragraph in DDK doc:
>>>
>>> "In order to support 802.1Q packet information, a miniport driver must be
>>> implemented to mark packets with 802.1Q information and to remove such
>>> marking from packets. A miniport driver that supports 802.1Q packet
>>> information must also be able to specify such support. The following
>>> topics
>>> describe how to implement 802.1Q support"
>>>
>>> By this paragraph, it seems that 802.1Q/p 32-bit field exist only in NIC
>>> driver and it is removed when passed to upper IM driver and when packet is
>>> sent, 32-bit field is added in NIC driver.
>>> And you wrote that 32-bit field is still present in PtReceive() in IM
>>> driver.
>>>
>>> Am I understanding this DDK doc paragraph wrong ?
>>>
>>> Peter
>>>
>>> "Peter" wrote:
>>>
>>>> I'd like to be sure if this assumption is correct:
>>>> NIC driver supports VLAN and there is installed NDIS 5.1 IM driver.
>>>> For 802.1Q/p frame there is added a 32-bit field between the source MAC
>>>> address and the Ethernet Type.
>>>> When receiving packet is indicated in IM driver and consequently is
>>>> called
>>>> ProtocolReceive(),
>>>> Is this 32-bit field always removed from packet when reaching
>>>> ProtocolReceive() ?
>>>> (Has ethernet frame in IM driver always 14-byte header in format:
>>>> DestMAC,SrcMAC,EthType followed by next protocol header)
>>>> ?
>>>>
>>>> Thanks !
>>>> Peter
>>