On 27/3/09 10:06 AM, "Thomas M. Knoll"
Dear Mr. Hall and Mr. Newbery,
thank you for your replies and the current IX setup description. If I understand you right, the big majority of the customer base is untagged and some (e.g. TCL) is tagged.
Currently, all is untagged. The TCL position is just that---were QoS to be enabled, then that would be our proposal.
Comming to the possible use cases of 802.1p at an exchange.
2) QoS-enabled peering with layer 3 DSCPs If a peer C distinguishes e.g. 4 DSCPs and peers with A (running 12 DSCPs) and B (running 3 DSCPs) there needs to be set up a mapping between A+C and B+C on how to map the DSCPs arriving at C's port. However, neither the IP destination nor the IP source address can give C the clue, which peer the arriving packet came from. There are two options: a) match the sending MAC b) agree on the marking in the encapsulating layer, hence the 802.1p.
The peers REALLY need to work out what they are going to do with each others' QoS first. If A peers with B, then they must bilaterally or globally agree how DSCPs are handled---does AF31 even mean the same thing to each of them? Then they need to agree what DSCPs will be sent, and how to handle out of spec packets: options include dropping; remarking; shutting down the peering session; treating them as if they were in another CoS; etc.. If there were multiple bilateral policies with different peers in place, then having them all fetch up on the same port does not seem sensible to me. At the very least you would separate them into different VLANs.
All that is entirely independant from the CoS concept I am proposing at the IETF. Dylan, you are right, that I am sending class of service marking and mapping (DSCP<->EXP<->802.1p<->VC) information within BGP attributes, which in the common route server case, will not be been exchanged mutually between peers, but rather between the route server and all of its clients. Those marking attributes are of transitive type with IANA number 0x04 and will be relayed by the route server. As of quagga 0.99.10, no extra action was required to get the few attribute bytes relayed to the clients.
Therefore, I am trying to find out about Internet exchange points, which would a least transparently (untouched) transfer user priority bits across their platform and might even have 802.1p enqueueing and scheduling enabled on their switches.
My view is that the packet CoS marking should (must) be preserved end to end, but that what happens on each link is up to the parties running each link. In particular, there is no guarantee that 802.1p bits will transit untouched. For example, some equipment reserves the highest priority to itself for management/maintenance, so it may be considered unacceptable to have user traffic with 0x7 as a priority. At each layer 2 link, the appropriate 802.1p/EXP/... bits will be set based on the DSCP bits/VC/... etc.. If you do need to relay frames across the network, then you encapsulate them in L2TP or some such. -- Michael Newbery IP Architect TelstraClear Limited TelstraClear. Simple Solutions. Everyday Residential 0508 888 800 Business 0508 249 999 Enterprise & Government 0508 400 300 This email contains information which may be confidential and subject to copyright. If you are not the intended recipient you must not use, distribute or copy this email or attachments. If you have received this email in error please notify us immediately by return email and delete this email and any attachments. TelstraClear Limited accepts no responsibility for changes made to this email or to any attachments after transmission from TelstraClear Limited. It is your responsibility to check this email and any attachments for viruses. Emails are not secure. They can be intercepted, amended, lost or destroyed and may contain viruses. Anyone who communicates with TelstraClear Limited by email is taken to accept these risks.