Which QoS Model Fits 5G Backbone Marking Requirements
Mobile service provider "A" is going to launch 5G support with the ISP "B" IP network backbone as the underlay transport. Conversational traffic type will be marked with expedited forwarding class, streaming services will be marked with assured forwarding 2 class, and web browsing will be marked with assured forwarding 3 class. Which QoS model meets these requirements if the solution is to be implemented end to end on the ISP_B backbone network?
Community Insight
The question tests mapping of a stated marking scheme onto a Cisco QoS class model, and the trap is assuming a larger 8- or 12-class hierarchy is needed when only EF, AF2 and AF3 plus best effort are specified.
This 300-420 question asks which QoS model satisfies a 5G operator's marking plan of EF for conversational traffic, AF2 for streaming and AF3 for web browsing, deployed end to end across the ISP B backbone. Because only three marked classes plus default best effort are required, a 4-class DiffServ strategy is the correct choice.
Option B (8-class DiffServ) is the most tempting wrong pick because learners associate backbone QoS with Cisco's larger production class models; but the requirements name only three marked classes, so extra classes add no value. Options C and IntServ-based D are wrong because RSVP-style per-flow IntServ does not scale end to end across a service provider backbone.
Community Discussion (2 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
Conversational 5G traffic is explicitly marked EF, streaming is marked AF2, and web browsing is marked AF3, and unclassified traffic always falls into the default best-effort class. That yields exactly four distinct forwarding classes — EF, AF2, AF3 and best effort — which is precisely what a 4-class QoS strategy defines. DiffServ is also the required model because the design must run end to end across the ISP B backbone, where per-hop behavior based on DSCP markings scales, whereas IntServ/RSVP requires per-flow signaling that cannot be sustained over a full service provider core. Option A therefore satisfies both halves of the requirement: the correct class count and the correct architecture.Why the Other Options Are Wrong
Option B, an 8-class DiffServ strategy, would be a valid Cisco design in general, but it introduces classes the scenario never asks for (such as scavenger, network control or additional AF levels), so it over-provisions beyond the stated requirements. Options C and D both specify the IntServ model, which relies on per-flow resource reservation and is explicitly unsuitable for an end-to-end backbone deployment because of its signalling overhead and poor scalability; they also pair IntServ with 6- and 12-class counts that do not match the three marked DSCPs plus best effort described here. Choosing any IntServ option fails the "end to end on the ISP_B backbone" clause regardless of class count.Community Comment Notes
Commenter MaxwellJK identified the correct mapping, noting "EF = conversational / real-time traffic" with "AF2 = streaming AF3 = web browsing plus Best Effort/default traffic", which totals four classes. A second learner simply endorsed that reasoning, stating "You do not need more than 4 classes." Both community votes land on option A, and independent analysis of the marking plan confirms that consensus is correct rather than merely a popularity pick.Official Reference
Exam Strategy
Read the scenario's marking statements first and count the distinct DSCPs plus best effort — that count is the class model answer. Then check the deployment scope: "end to end on the backbone" is the signal that DiffServ, not IntServ, is required.
Frequently Asked Questions
Why isn't an 8-class DiffServ model needed when this is a service provider backbone?
The scenario only defines three marked classes — EF, AF2 and AF3 — plus unclassified traffic that lands in best effort. An 8-class model adds classes the requirements never specify, so 4 classes suffice.
Why can't IntServ be used for an end-to-end design on the ISP B backbone?
IntServ uses per-flow RSVP reservation signalling, which does not scale across a full service provider core. DiffServ applies per-hop behaviour based on DSCP markings and is the standard for backbone-wide QoS.
Related Analysis
Practice All 300-420 Questions
Access 150 questions with complete answers and detailed explanations.
View Full 300-420 Practice Test →