* Patrik Lahti | 2010-07-07 13:55:17 [-0400]: >I'm of the opinion that IPv6 Neighbor Discovery packets are important >to keep the network functioning and perhaps should be classified as >network or internetwork control packets and be prioritized >accordingly.
See RFC 4594, section 3 >Currently many implementations send Neighbor Discovery traffic using >the default (Best Effort, i.e. zero) DSCP value, and e.g. if other >higher priority traffic (lets say a lot of voice traffic) is >competing for bandwidth then ND may cease to function correctly >potentially leading to all sorts of havoc. Hosts can't get addresses, >can't detect if they're duplicate, can't find default routers, etc. >Even if the outage is temporary, the user experience may already have >suffered. > >Yes, ND is only used on the link, and no routers would look at the >DSCP in ND messages when forwarding. However, the network stack using >internal QoS mechanisms may experience congestions locally, and link >level devices may experience congestion too and the DSCP is often >mapped into link layer QoS mechanisms. > >What are your thoughts? Can you shed some light on this topic? Does >this fall into implementation defined behaviour? Yes and no. RFC 4594, section 3 talk about Network Control Traffic: Network control traffic is defined as packet flows that are essential for stable operation of the administered network as well as for information that may be exchanged between neighboring networks across a peering point where SLAs are in place. Network control traffic is different from user application control (signaling) that may be generated by some applications or services. Network control traffic is mostly between routers and network nodes that are used for operating, administering, controlling, or managing the network segments. Network Control Traffic may be split into two service classes, i.e., Network Control and OAM. The RFC focus on routing protocols (OSPF, BGP, ISIS, RIP). But your are right, ND can and should also be treated as network control traffic. You already mentioned it, the scope of link local traffic is limited but I am aware of some environments where the network layer DSCP is the basis for link layer queueing and 802.3p CoS marking. Concrete example (Linux centric): tc qdisc add dev eth0.1 root handle 1: prio tc filter add dev eth0.1 parent 1:0 protocol all u32 match u32 0 0 action skbedit priority 3 Later on the RFC _recommends_ for network control traffic DSCP marking CS6 (Class Selector 6). And this is the most important fact: it is and should be a suggestion because quality of service and DiffServ marking is a _operational requirement_. There can be environments where network control traffic should be treated as DF (Default Forwarding). Think about low latency trading environment with several priority levels. You cannot and should not artificial limit the system by dictate the use of DSCP - the recommendations are sufficient. Cheers, Hagen -- Hagen Paul Pfeifer <ha...@jauu.net> || http://blog.jauu.net/ Telephone: +49 174 5455209 || Key Id: 0x98350C22 Key Fingerprint: 490F 557B 6C48 6D7E 5706 2EA2 4A22 8D45 9835 0C22 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
