Annex Q (normative)	
DMN (Designated MSRP Node) Implementations
This annex describes the DMN implementation on a CSN (Coordinated Shared Network), with network specific implementations for MoCA networks and IEEE Std 802.11 wireless networks.
Q.1 	Designated MSRP nodes on CSNs
A CSN is a contention-free, time-division multiplexed-access network, supporting reserved bandwidth based on priority or flow (QoS).  One of the nodes of the CSN acts as the Network Coordinator (NC) node, granting transmission opportunities to the other nodes of the network. The NC node also acts as the bandwidth resource manager of the network.
Q.1.1 	Coordinated Shared Network (CSN) characteristics
CSNs support two types of transmissions: unicast transmission for node-to-node transmission and multicast/broadcast transmission for one-node-to-other/all-nodes transmission. Each node-to-node link has its own bandwidth characteristics which could change over time due to the periodic ranging of the link. The multicast/broadcast transmission characteristics are the lowest common characteristics of multiple/all the links of the network.
A CSN network is physically a shared network, in that a CSN node has a single physical port connected to the half-duplex medium, but is also a logically fully-connected one-hop mesh network, in that every node could transmit to every other node using its own profile over the shared medium.
 Figure Q-1  illustrates a CSN network acting as a backbone interconnecting AV systems.

Figure Q-1—	CSN Backbone
Depending on the CSN technology, the Network Controller node may either be a fixed node or may be dynamically selected during normal operation.
Q.1.2 	Designated MSRP Node handling on CSN
From the bandwidth reservation stand point a CSN network is modeled as a Bridge as illustrated by  Figure Q-2. Each node-to-node link is equivalent to the path from an input to an output Bridge’s port.

Figure Q-2—	Bridge’s CSN Model for Bandwidth Reservation
A CSN provides a single entity called the Designated MSRP Node or DMN (35.1.1) to manage the CSN bandwidth resources for the MSRP streams. Q.1.2.1 	DMN Selection and Migration
Depending on the CSN technology, the DMN might correspond to a static node or dynamically migrate between nodes during normal operation. The DMN selection is network specific and described in  Q.2.1 and  Q.3.2.
Over time the DMN constructs its database by handling the MSRP Talker and Listener Declarations generated by the nodes of the CSN. If the DMN migrates, the new DMN broadcasts an MRP LeaveAll message to all the nodes of the CSN which will force its neighbors to re-declare their attributes. The MSRP Participant nodes answer the MRP LeaveAll message by sending an MRP JoinIn message consumed by the DMN as an MRP Re-Declare! message. These re-declarations permit the new DMN to immediately build its database.
Q.1.3 	MSRPDU handling on a CSN
 Figure Q-3  and  Figure Q-4 illustrate the flow and handling of MSRPDU messages on a CSN.

Figure Q-3—	Talker MSRPDU flow

Figure Q-4—	Listener MSRPDU flow
1)		CSN nodes identify MSRPDUs by their Group Destination Address (35.2.2.1), and encapsulate them in regular CSN data frames, then multicast or broadcast them, as appropriate, over the CSN.
2)		The CSN node that is the DMN will forward the MSRPDUs to the DMN entity.
3)		The DMN translates the MSRP TSpec parameters into CSN QoS parameters and invokes the CSN’s Protocol Specific QoS transactions with the CSN Network Controller ( Q.2.2,  Q.3.3) as follows:
a)		When the DMN receives a Talker Advertise message originated from an upstream CSN node, the DMN invokes a bandwidth query transaction with the CSN Network Controller to check whether or not the bandwidth advertised in the message’s TSpec is available on each upstream to downstream node link of the CSN network. In addition the DMN maps the MSRP TSpec with the message’s StreamID.
b)		When the DMN receives a Listener Ready message originated from a downstream CSN node, the DMN invokes a bandwidth reservation transaction with the CSN QoS manager to reserve the bandwidth associated with the message’s StreamID on the downstream to upstream CSN node link.
4)		After the DMN completes the CSN QoS transactions, the DMN behaves as an MSRP application on a Bridge and propagates MSRP attributes (35.2).
Q.2 	Designated MSRP Node on MoCA
NOTE—The discussion that follows is based on terminology found in the MoCA Specifications [B37][B38][B39].
Q.2.1 	DMN Selection on MoCA Network
Q.2.1.1 	DMN capable node discovery
A DMN capable node will append the IEEE DMN Device Attribute Information Element ( Q.2.1.2) to the L2ME payload of the Device Discovery Protocol SUBMIT L2ME transaction message specified in the MoCA v2.0 Specification [B39].
Upon completion of the L2ME Device Discovery transaction all the DMN-capable nodes of the MoCA network share the same information: 
1)		which MoCA nodes are DMN capable,
2)		which MoCA node is selected as the DMN. 
If no DMN is selected, the DMN selection will be performed ( Q.2.1.3)
Q.2.1.2 	IEEE DMN Device Attribute IE
Q.2.1.2.1 	General
The fields of the IEEE DMN Device Attribute IE are specified in  Table Q-1 and  Q.2.1.2.2 through Q.2.1.2.7. The general format of the Device Attribute Information Element is described in the MoCA v2.0 Specification [B39].

Table Q-1—	IEEE DMN Device Attribute IE
Q.2.1.2.2 	ATTRIBUTE_ID (Enumeration8)
The value of the ATTRIBUTE_ID is 0xFF.
Q.2.1.2.3 	LENGTH (UInteger8)
The value of the LENGTH is 1.
NOTE—The actual length of the Attribute IE in bits is (LENGTH + 1 ) * 32.
Q.2.1.2.4 	VENDOR_ID (Enumeration16)
The value of VENDOR_ID is <<IEEE_VENDOR_ID>>.
<<Editor’s Note: This ID will be assigned  before the document is published. >>
Q.2.1.2.5 	TLV_TYPE (Enumeration16)
The value of the TLV_TYPE is 1 (SRP). 
Q.2.1.2.6 	TLV_LENGTH (UInteger8)
The length of the TLV in octets is 4.
Q.2.1.2.7 	TLV_VALUE (Octet2)
The meaning of the field of the TLV_VALUE are specified as described in  Q.2.1.2.7.1 through  Q.2.1.2.7.3.
Q.2.1.2.7.1 	DMNcapable (Bit 0 - Boolean)
A value of 1 indicates the node is capable of acting as the DMN of the network. A value of 0 indicates the node is not capable to act as a DMN.
Q.2.1.2.7.2 	DMNselected (Bit 1 - Boolean)
A value of 1 indicates the node has been selected as the DMN of the network. A value of 0 indicates the node is not the selected DMN.
Q.2.1.2.7.3 	Reserved (Bit 2..15)
These bits are reserved for future usage.
Q.2.1.3 	DMN selection and confirmation
If either 1) the NODE_BITMASK field into MAP frames indicates that the selected DMN has been removed from the network (due to failure, power state/down, etc.) or 2) the DMN node discovery ( Q.2.1.1) does not indicate a DMN selected node, the DMN capable node with the lowest node ID will start acting as the DMN and confirm the selection to the other DMN capable nodes by generating a L2ME DMN Confirmation Transaction ( Q.2.1.3.1).
NOTE—”MAP frame” is defined in the MoCA v1.0 Specification [B37].
Q.2.1.3.1 	L2ME DMN Confirmation Transaction
Q.2.1.3.1.1 	Overview of DMN ConfirmationTransaction
 Figure Q-5  provides an overview of the signals exchanged among the nodes during an L2ME DMN Confirmation Transaction. As shown in the figure, the NC node starts the transaction either when it receives a Submit L2ME Frame from a node (called the DMN Selected Entry Node for that Transaction) or on its own. The transaction includes two L2ME Waves. The details of each message exchanged during the  DMN Confirmation Transaction are provided below.

Figure Q-5—	DMN ConfirmationTransaction
Q.2.1.3.1.2 	DMN Confirmation Submit
The DMN Confirmation Transaction starts when the DMN Selected Entry Node sends a Submit L2ME Frame to the NC. 
The general fields of the Submit L2ME frame are as specified in Section 2.2.3.1. of the MoCA v1.1 Specification [B38]. The parameters in the Submit L2ME Frame are set as follows:
a)		VENDOR_ID = <<IEEE_VENDOR_ID>>
<<Editor’s Note: .see note in  Q.2.1.2.4. >>
b)		TRANS_TYPE = 0x1 (SRP)
c)		TRANS_SUBTYPE = 0x1 (DMN Confirmation)
d)		WAVE0_NODEMASK = (DMN capable nodes)
e)		MSG_PRIORITY = 0xF0
f)		TXN_LAST_WAVE_NUM = 0x1
g)		L2ME_PAYLOAD = 0 bytes
Q.2.1.3.1.3 	Request L2ME Frame of Wave 0 of DMN Confirmation Transaction
In the Wave 0 that follows the DMN Confirmation Submit message, the NC node initiates a Request L2ME Frame based on the Submit L2ME Frame.
The general fields of the Resquest L2ME frame are as specified in the in Section 2.2.3.2. of the MoCA v1.1 Specification [B38].
Q.2.1.3.1.4 	Response L2ME Frame of Wave 0 of DMN Confirmation Transaction
Each of the requested DMN capable nodes sends a Response L2ME Frame to acknowledge the confirmation request.
The general fields of the Response L2ME frame are as specified in Section 2.2.3.3. of the MoCA v1.1 Specification [B38]. The parameters in the Response L2ME Frame are set as follows:
a)		RESP_STATUS <INTERPRETED> = ’1’ 
b)		RESP_STATUS <IN_NEXT_WAVE> = ’1’
c)		L2ME_PAYLOAD  = 0 bytes
Q.2.1.3.1.5 	Request L2ME Frame of Wave 1 of DMN Confirmation Transaction
In Wave 1, the NC node informs the DMN capable nodes about the acknowledgement results from Wave 0. The NC node initiates Wave 1 using a Request L2ME Frame with the “concatenated” type of L2ME_PAYLOAD. 
The general fields of the Request L2ME frame are as specified in Section 2.2.3.1. of the MoCA v1.1 Specification [B38]. The “concatenated“ L2ME_Payload are as specified in Table 2-4 of the MoCA v1.1 Specification [B38].
Q.2.1.3.1.6 	Response L2ME Frame of Wave 1 of DMN Confirmation Transaction
The DMN Confirmation Transaction is completed when the DMN Selected Entry node and the other DMN capable nodes send their final Response L2ME Frame to the NC node.
The general fields of the Response L2ME frame are as specified in Section 2.2.3.3. of the MoCA v1.1 Specification [B38].The parameters in the Response L2ME Frame are set as follows:
a)		RESP_STATUS <INTERPRETED> = ’1’ 
b)		RESP_STATUS <IN_NEXT_WAVE> = ’0’
c)		L2ME_PAYLOAD  = 0 bytes
Q.2.2 	MoCA network bandwidth management
The DMN entity within the MoCA network manages the MoCA bandwidth for the MSRP streams by invoking the MoCA native PQoS transactions. The DMN maps the MSRP Attribute Declaration and the resultant MAD declarations as described in  Table Q2.
Table Q2—	SRP to MoCA PQoS Transaction mapping	
MSRP Attribute	MAD Primitive	MoCA PQoS
Transactions	Description	
Talker Advertise	MAD_Join.request(new)	Create PQoS Flow	Query bandwidth without reservation
NOTE—MoCA PQoS APIs do not include a Bandwidth Query specific API. Therefore, bandwidth is queried by invoking a CreatePQoSFlow reservation for more bandwidth than the network could provide. The request will fail and CreatePQoSFlow will then return a failure status which includes the bandwidth available for reservations.	
Listener Ready or
Listener Ready Failed	MAD_Join.request(new)	Create PQoS Flow	Reserve bandwidth for a stream	
Listener Ready or
Listener Ready Failed	MAD_Join.request()	Update PQoS Flow	Renew the bandwidth reservation
(leased time) for a stream	
Talker or Listener Leave	MAD_Leave.request()	Delete PQoS Flow	Free bandwidth associated with a stream	

 Table Q3  describes the mapping between SRP TSpec components and MoCA PQoS TSPEC parameters.
Table Q3—	SRP TSpec to MoCA TSPEC mapping	
SRP TSpec	MoCA PQoS TSPEC	
MaxFrameSize	Max Packet Size	
MaxFrameSize * MaxIntervalFrames	Peak Data Rate	
MaxFrameSize * MaxIntervalFrames * Class B class measurement interval (34.4)	(Max) Burst Size	

 Table Q4 
Table Q4—	SRP StreamID to MoCA PQoS Flow transaction mapping	
SRP StreamID	MoCA PQoS Flow Transaction	
	Transaction	L2ME Payload	Field	
48-bit MAC Address	Create PQoS Flow
Update PQoS Flow	Submit	PACKET_DA	
	Query PQoS Flow	Response		
16-bit Unique ID	Create PQoS Flow
Update PQoS Flow	Submit	FLOW_TAG	
	Query PQoS Flow	Response		
 describes the mapping of the SRP StreamID to MoCA PQoS Flow transactions. The MoCA Flow parameters includes a 32-bit field that allows an application, like SRP, to store application specific information. SRP will use this field (FLOW_TAG) to store the 16-bit unique ID portion of the StreamID.
Q.3 	Designated MSRP Nodes on IEEE Std 802.11 media
From the bandwidth reservation standpoint an IEEE Std 802.11 BSS network is modeled as a Bridge as illustrated by  Figure Q-6,  Figure Q-7 and  Figure Q-8. Each STA-AP link, STA-AP-STA link  and optional STA-STA DLS direct link is equivalent to the path from an input to an output Bridge’s port.

Figure Q-6—	Bandwidth Reservation - Bridge Model for IEEE 802.11 BSS (STA Downstream Port)

Figure Q-7—	Bandwidth Reservation - Bridge Model for IEEE 802.11 BSS (STA Upstream Port)

Figure Q-8—	Bandwidth Reservation - Bridge Model for IEEE  802.11 BSS (Direct Link Setup)
 An IEEE Std 802.11 BSS  provides a single entity called the Designated MSRP Node (DMN) (35.1.1) to manage the BSS bandwidth resources for the MSRP streams..

Q.3.1 	MSRP Handling
MSRPDUs are transparently transported by the Std 802.11 BSS network and delivered to the DMN. 
The DMN maps the MSRP commands into IEEE Std 802.11 MLME TS commands and interacts with the AP through the AP’s MLME SAP.
 Figure Q-9  describes the flow between the MSRP and IEEE Std 802.11e messages. 

Figure Q-9—	MSRP/802.11e Flows
<<Editor’s Note: MLME-QUERY.Request, MLME-QUERY.Confirm, MLME-RESERVE.Request, MLME-RESERVE.Confirm, Reserve Request action frame and Reserve Response action frame need to be defined in 802.11. They will be part of 802.11aa.>> 
1)		BBS nodes identify MSRPDUs by their Group Destination Address (35.2.2.1) and multicast these PDUs to the AP.
2)		The AP forwards the MSRPDUs to the DMN entity.
3)			The DMN translates the MSRP TSpec parameters into IEEE Std 802.11 QoS parameters and invokes MLME QoS transactions with the AP as follows:
a)		When the DMN receives a Talker Advertise message originated from an upstream BSS node, the DMN invokes QoS Query transactions (MLME-QUERY.Request) with the BSS QoS Manager to check whether or not the bandwidth advertised in the message’s TSpec is available on each upstream to downstream node link of the BSS. In addition the DMN maps the MSRPDU’s TSpec with the message’s StreamID.
b)		When the DMN receives a Listener Ready message originated from a downstream BSS node, the DMN invokes a QoS Reservation transaction (MLME-RESERVE.Request) with the BSS QoS manager to reserve the bandwidth associated with the message’s StreamID on the downstream to upstream BSS node link.
4)		After the DMN completes the BSS QoS transactions, the DMN behaves as an MSRP application on a Bridge and propagates MSRP attributes (35.2).
Q.3.2 	BSS DMN selection
On an IEEE Std 802.11 BSS the DMN is always co-located with the AP.
Q.3.3 	BSS network bandwidth management
The DMN entity within the IEEE Std 802.11 network manages the BSS bandwidth for the MSRP streams by invoking the MLME QoS services. The DMN maps the MLME services as described in  Table Q5.
Table Q5—	SRP to MLME QoS Services mapping	
MSRP Attribute	MAD Primitive	MLME QoS
Services	Description	
Talker Advertise	MAD_Join.request(new)	MLME-QUERY	Query bandwidth without reservation	
Listener Ready or
Listener Ready Failed	MAD_Join.request(new)	MLME-RESERVE	Reserve bandwidth for a stream	
Listener Ready or
Listener Ready Failed	MAD_Join.request()	MLME-RESERVE	Renew the bandwidth reservation
(leased time) for a stream	
Talker or Listener  Leave	MAD_Leave.request()	MLME-DELTS	Free bandwidth associated with a stream	

 Table Q7  describes the mapping between SRP TSpec components and IEEE Std 802.11 QoS TSPEC parameters for EDCA.Table Q-6—	EDCA-AC for AV Streams	
TSPEC Parameter	AV Stream 	
	802.1D Priority 4	802.1 D Priority 5	
TSINFO	TID	0-7	0-7	
	Direction	Up, Down	Up, Down	
	Access Policy	10 (EDCA)	10 (EDCA)	
	ACK Policy	10 (No Ack) / 
11 (Block Ack)	10 (No Ack) / 
11 (Block Ack)	
	APSD	0	0	
	Aggregation	Yes	Yes	
	Priority	4	5	
Nominal MSDU Size 	SRP TSpec MaxFrameSize	
Maximum MSDU Size		1500 bytes	1500 bytes	
Delay Bound	29 uSec	29 uSec	
Mean Data Rate		SRP TSpec MaxFrameSize * 
SRT TSpec MaxIntervalFrames 	
Minimum PHY Rate	 	11.44 * SRP TSpec MaxFrameSize * 
SRT TSpec MaxIntervalFrames 	
Surplus Bandwidth Allowance		1.2	1.2	

		

		

		

<<Editor’s Note: A table similar to  Table Q-6 is required for HCCA>>