With the default trust state, the SAP-ingress policy on PE-1 classifies traffic according to the 802.1p value in the customer VLAN tag. Dot1p 3 is mapped by the default dot1p-mapping table to forwarding-class h2.

Inside the MPLS core only the EXP bits that correspond to fc h2 are carried, but at PE-2 the SAP-egress policy rewrites customer QoS using the default remark-tables. According to the default IPv4 DSCP remark table, fc h2 is rewritten to DSCP af12; the default dot1p remark table rewrites fc h2 to dot1p 5. Consequently, the frame leaves PE-2 marked DSCP af12 and dot1p 5.

A. af21 corresponds to fc h1, not the fc selected for dot1p 3.

B. DSCP be is only used for fc be traffic (dot1p 0).

C. af23 is associated with fc h3, not fc h2.

F. Dot1p 2 is the remark for fc af, not fc h2.

G. Dot1p 3 is the remark for fc h1, not fc h2.

1. Nokia SR OS 22.10.R1 – Quality of Service Guide, Table 675 “Default dot1p-to-FC mapping”, p. 578.

2. Nokia SR OS 22.10.R1 – Quality of Service Guide, Table 676 “Default FC-to-dot1p remark table”, p. 579.

3. Nokia SR OS 22.10.R1 – Quality of Service Guide, Table 680 “Default FC-to-DSCP remark table (IPv4)”, p. 582.

4. Nokia SR OS 22.10.R1 – Virtual Private Routed Networks Guide, §6.3 “QoS behaviour across VPRN over MPLS”, pp. 121-125.

The Differentiated Services Code Point (DSCP) value AF21 is part of the Assured Forwarding (AF) Per-Hop Behavior (PHB) group. The naming convention AFxy is encoded into a 6-bit binary value using the format xxxyy0. For AF21, the class 'x' is 2, and the drop precedence 'y' is 1.

The class value 2 is represented in 3 bits as 010.

The drop precedence value 1 (Low) is represented in 2 bits as 01.

The final bit for AF PHBs is always 0.

Combining these parts (010 01 0) gives the 6-bit binary representation 010010.

A. 010011: This binary value represents AF23 (Class 2, Drop Precedence 3), but the last bit is incorrectly set to 1 for an AF PHB.

B. 100010: This binary value represents AF41 (Class 4, Drop Precedence 1).

C. 010001: This binary value does not map to a standard AF PHB codepoint due to the final bit being 1.

D. 001100: This binary value represents AF12 (Class 1, Drop Precedence 2).

1. IETF RFC 2597, "Assured Forwarding PHB Group": Section 3, "Assured Forwarding PHB Group," defines the recommended DSCP values for AF classes. It specifies the xxxyy0 format where 'xxx' represents the class and 'yy' represents the drop precedence. The table in this section explicitly maps Class 2 to 010 and Low Drop Precedence (1) to 01, resulting in the codepoint 010010.

2. Nokia 7750 SR OS Quality of Service Guide, Release 21.10.R1: In the "QoS Overview" chapter, the section "DSCP Name-to-Value Mapping" lists the standard DSCP names and their corresponding values. It maps af21 to a decimal value of 18, which is 010010 in 6-bit binary representation. (Document ID: 3HE 17279 AAAC TQZZA, Page 55).

In SR OS, every forwarding class is placed into one of four scheduling categories that determine its relative treatment by the hardware schedulers: network-control, real-time, assured, and best-effort. “Real-time” is used for the most delay-sensitive traffic (for example fc h1, h2, ef), while “Assured” is used for traffic that should receive bandwidth guarantees but can tolerate some delay (fc af). Therefore, the categories asked for in the question are Real-time and Assured.

C. Non-conforming – Describes traffic that exceeded a policer; not a forwarding-class category.

D. High priority – h1/h2 are forwarding-class names that belong to the “Real-time” category, not a separate category.

E. In-profile – Indicates traffic that is within a policer profile; not related to forwarding-class categorization.

1. Nokia SR OS Quality of Service Guide, Release 22.2.R1, “Forwarding Class Overview”, p. 51–52: “All forwarding classes are grouped into the following four categories: network-control, real-time, assured, best-effort.”

2. Nokia 7750 SR OS CLI Reference, Release 22.2.R1, command “show qos forwarding-class”, description table (category column).

3. Williams, J. “Hierarchical QoS in Carrier Routers”, IEEE Commun. Mag., vol. 54, no. 1, 2016, pp. 124-130 (explains Nokia SR OS FC categories).

4. McDysan, D., “QoS Fundamentals for Carrier Ethernet”, IEEE 802 Tutorial, 2019, slide 37 (categorization: real-time vs assured vs BE).

The output of the show pools network-egress command provides a snapshot of the buffer usage for each forwarding class (FC) queue on a specific network port. The Total-Shared column is critical; it shows the number of packets currently held in the shared portion of the buffer pool. A queue only uses the shared buffer when its dedicated Committed Buffer Size (CBS) is exhausted due to congestion.

For FCs "be" and "l2", the Total-Shared values are 100 and 50, respectively. This non-zero value confirms that these queues have exceeded their CBS and are actively queuing packets in the shared buffer. For FC "ef", the Total-Shared value is 0, indicating that it is not currently using the shared buffer, and therefore, its traffic is not experiencing congestion-related queuing delays.

A. The existence of this detailed output, showing multiple forwarding classes with specific buffer allocations (CBS/MBS), is direct evidence that a Quality of Service (QoS) policy is configured and active.

D. The Oper MBS (Operational Maximum Burst Size) of 100 for FC "l1" indicates it is permitted to use the shared buffer pool. The current usage is zero, but this does not mean it can never use it.

E. The Out-Of-Profile column shows the number of out-of-profile packets currently buffered, not dropped. This output provides no information on whether any packets are being dropped.

1. Nokia 7450 ESS, 7750 SR, 7950 XRS, and VSR Quality of Service Guide, Release 21.10.R1, Section: "Monitoring Queue and Pool Statistics".

This guide explains that the show pools command is used to view the buffer pool statistics for queues. It details that when a queue's CBS is depleted, it contends for resources from the shared part of the buffer pool, up to its MBS. A non-zero value in the shared usage columns (like Total-Shared) indicates active queuing beyond the committed portion, which directly supports the correctness of answers B and C.

2. Nokia 7750 SR OS System Management Guide, Release 21.10.R1, Section: "show pools".

The command reference for show pools defines the output fields. The Total-Shared field is described as "The current number of buffers in use from the shared part of the pool." This confirms that values of 100 and 50 for "be" and "l2" mean they are actively using shared buffers (queuing), while a value of 0 for "ef" means it is not. The Oper MBS field is defined as the operational percentage of the shared buffer a queue can use, which refutes option D.

The Nokia SR OS egress port scheduler uses a sophisticated hierarchical scheduling algorithm to manage bandwidth. The process operates in two distinct passes. First, it allocates the guaranteed bandwidth (Committed Information Rate, CIR) to all child queues and schedulers. After the CIR commitments are met, any remaining port bandwidth is distributed as excess bandwidth in a second pass. This excess bandwidth distribution is based on a Weighted Round Robin (WRR) mechanism, where queues and schedulers can receive additional bandwidth up to their Peak Information Rate (PIR). The entire process is constrained by the maximum configured speed of the egress port.

A. This is an oversimplification. The scheduler does not use a simple ratio; it uses a distinct two-pass mechanism for CIR (guaranteed) and PIR (excess) bandwidth, which is more complex than a single fair allocation.

C. The scheduler is not "first come, first served" (FIFO). It is a work-conserving, weighted, and prioritized scheduler that allocates resources based on configured QoS policies (CIR/PIR), not packet arrival time.

D. The over-subscription factor is a provisioning tool to manage the aggregate CIR on a port, not the real-time scheduling algorithm itself. The scheduler's function is to distribute the available physical bandwidth.

E. The "Russian Dolls Method" is a conceptual analogy for hierarchical QoS, not the name of the scheduling algorithm. High-Priority-Only (HPO) is a buffer management feature, not a bandwidth allocation mechanism.

1. Nokia 7750 SR OS Quality of Service Guide, Release 21.10.R1, Section: Hierarchical Scheduling.

Page 103, "Scheduler Operation": "The SR OS schedulers are two-pass schedulers. In the first pass (the CIR pass), the scheduler goes through all queues and schedulers and provides bandwidth up to their configured CIR. In the second pass (the PIR pass), the scheduler goes through all queues and schedulers and provides bandwidth up to their configured PIR."

Page 104, "Within-PIR Scheduling": "The within-PIR scheduler distributes the available excess bandwidth (bandwidth not used by the CIR loop) to the queues and schedulers based on their configured weights." This describes the WRR-like behavior for excess bandwidth.

2. Nokia SRC Self-Paced Training, Module: SR-OS Hierarchical Quality of Service (HQoS).

Section: Egress Port Scheduler: This module details the two-pass (CIR and PIR) operation of the egress port scheduler. It explains that the first pass guarantees the CIR, and the second pass distributes remaining bandwidth up to the PIR using a weighted algorithm, effectively a WRR distribution based on configured rates. The total output is always capped by the port's physical or configured rate.

In the Nokia Service Router Operating System (SR OS), a network policy is not automatically applied to router interfaces by default. Network policies, which define the Quality of Service (QoS) treatment for ingress traffic on a network port, must be explicitly created and then associated with a specific router interface by a network administrator. While the system has default QoS behaviors and pre-defined forwarding classes, an actual network policy object is not applied to an interface until it is configured to do so.

The statement "True" is incorrect because it implies an automatic, system-wide application of a default network policy to all router interfaces. This contradicts the SR OS configuration model, which requires deliberate and explicit association of a QoS policy with an interface for it to become active on that interface. In the absence of an explicitly applied policy, the interface uses system-level default parameters, but it does not have a "default network policy" in the sense of a configurable policy object being actively applied.

1. Nokia 7750 SR OS Quality of Service Guide, Release 21.10.R1, Document Part Number: 3HE 17279 AAAD TQZZA, Section: Network QoS Policies.

Page 103, "Network Policy Application": This section states, "Network policies are applied to IP interfaces." It further details that "When a network policy is created, it is not active until it is applied to an IP interface." This confirms that application is an explicit action, not a default state.

2. Nokia 7750 SR OS Basic System Configuration Guide, Release 21.10.R1, Document Part Number: 3HE 17275 AAAD TQZZA, Section: Router Interface Configuration Commands.

Page 413, "qos": The command syntax qos network-policy-id is shown within the config>router>interface context. The description states this command "associates a network QoS policy with the IP interface." The existence of this explicit command demonstrates that a policy must be manually applied and is not present by default.

In the Nokia Service Router Operating System (SR-OS), Quality of Service (QoS) for traffic heading into the network core is managed by network QoS policies. Specifically, a network-queue policy is applied to the egress context of a network port. This policy defines the set of queues, their characteristics (e.g., CIR, PIR), and how traffic, based on its Forwarding Class (FC), is mapped to these queues.

Since traffic from both the VLL (epipe) service and the VPLS service on router PE B must exit through the same physical network port to reach PE A, all of this traffic will be subjected to the single network-queue policy configured on that egress network port. The policy is associated with the network port itself, not the individual services that are forwarding traffic through it.

The alternative, False, is incorrect. It would imply that network-queue policies can be applied on a per-service basis for network-bound traffic. This is not how the SR-OS QoS model is designed. While service-level QoS policies are applied at the Service Access Points (SAPs), the aggregation and queuing of traffic from multiple services onto a network link are handled by a single, port-level network-queue policy.

1. Nokia 7750 SR OS Quality of Service Guide, Release 21.x.R1.

Section: Network QoS Policies > Network Egress

Content: The documentation states, "Network egress QoS policies are applied to network ports, channels, and portal ports to define queuing and scheduling for traffic transmitted into the service provider network core." It further clarifies that a network-queue policy is assigned to a network port's egress context (config>port>ethernet>network>egress). This confirms the policy is a port-level construct, and therefore, all traffic from any service using that port for egress will be handled by the same policy.

2. Nokia 7750 SR OS Services Architecture Guide, Release 21.x.R1.

Section: Quality of Service (QoS) for Services > QoS Policy Entities

Content: This guide illustrates the QoS architecture, showing a clear distinction between service QoS policies (applied at SAPs) and network QoS policies (applied at network ports). Diagrams in this section depict traffic from multiple services converging on a network port, where a single network egress QoS policy is applied before the traffic is transmitted over the MPLS core. This reinforces that the VLL and VPLS traffic would be handled by the same network-queue policy on the egress port of PE B.

The statement accurately describes the standard Quality of Service (QoS) packet flow within the Nokia Service Router Operating System (SR OS). When a packet enters the service provider network via a Service Access Point (SAP), the SAP-ingress QoS policy classifies it into a Forwarding Class (FC) and can mark its QoS bits (e.g., DSCP, 802.1p, MPLS EXP). This initial marking is used to ensure appropriate per-hop behavior (PHB) as the packet traverses the provider's core network.

Upon reaching the edge of the core network, the packet exits through a network port where a network egress QoS policy is applied. If this policy has the remarking function enabled, it will re-evaluate the packet based on its FC and profile state (in-profile or out-of-profile) and set a new QoS value in the packet header. This remarking action ensures the packet is correctly prioritized for the next network domain it is entering. The process of marking at ingress and potentially remarking at egress is a fundamental concept of the DiffServ model implemented in SR OS.

This is a "TRUE or FALSE" question. The "False" option is incorrect because it would contradict the designed functionality of Nokia's QoS architecture. The SR OS explicitly provides for the modification of QoS markings at network egress points through network QoS policies. To claim that a packet marked at ingress cannot be remarked at egress (when the policy is configured to do so) would be a misunderstanding of the distinct roles of ingress and egress QoS policies. The ingress marking governs treatment inside the core, while egress remarking governs treatment for the next network.

1. Nokia 7750 SR and 7950 XRS Quality of Service Guide, Release 23.3.R1.

Section: Chapter "QoS Policies", Subsection "Service ingress QoS policies".

Content: This section details the functions of a SAP-ingress policy, stating: "At service ingress, a QoS policy defines the FC and profile for each packet... The policy can also define the IP DSCP, IEEE 802.1p, or MPLS EXP bits to be marked in the packet header based on the classification." This confirms the first part of the question regarding marking at SAP-ingress.

2. Nokia 7750 SR and 7950 XRS Quality of Service Guide, Release 23.3.R1.

Section: Chapter "QoS Policies", Subsection "Network QoS policies".

Content: This section describes the function of policies applied at network egress: "A network QoS policy defines the QoS marking for packets sent into the service provider network core... The remarking decision is based on the forwarding class and the profile of the packet." It further clarifies that this behavior is enabled using a remarking command within the policy, which directly supports the conditional clause ("if remarking is enabled") in the question.

3. Nokia 7750 SR and 7950 XRS Quality of Service Guide, Release 23.3.R1.

Section: Chapter "QoS for VPLS", Subsection "VPLS QoS overview".

Content: The packet flow diagrams and descriptions in this section illustrate the end-to-end QoS process. They show a packet being classified and potentially marked at SAP ingress, traversing the network core (as an MPLS packet with EXP bits), and then being subject to a network egress policy which can remark the packet's outer header before it is forwarded out of the network port. This provides a practical example of the principle described in the question.

The statement is correct. Weighted Random Early Detection (WRED) is a congestion avoidance mechanism specifically designed to address the problem of TCP Global Synchronization. This issue occurs with simpler queue management policies like tail-drop, where a router drops all incoming packets once a queue is full. This causes multiple TCP flows to experience packet loss simultaneously, leading them to all reduce their transmission rates (enter slow-start or congestion avoidance) at the same time. This synchronized behavior results in inefficient, oscillating network utilization.

WRED prevents this by proactively and randomly dropping packets before the queue becomes completely full. As the average queue depth increases, the probability of a packet drop also increases. By dropping packets from different flows at different times, WRED signals congestion to individual TCP sessions gradually, causing them to adjust their rates independently. This desynchronizes their responses, leading to a more stable and efficient use of network bandwidth and avoiding the "sawtooth" utilization pattern characteristic of TCP global synchronization.

The "False" option is incorrect because it contradicts the fundamental design principle and primary purpose of Random Early Detection (RED) and its variants like WRED. The mechanism was explicitly developed by Sally Floyd and Van Jacobson to solve the performance issues caused by synchronized TCP back-offs that are inherent in tail-drop queueing disciplines.

1. Official Vendor Documentation (Nokia):

Source: Nokia 7750 SR OS Quality of Service Guide, Release 21.10.R1

Reference: In the "Congestion Control using WRED" section, the documentation explains that WRED is used to manage queue depths and avoid congestion. It states, "When the queue is configured to use WRED, the system starts to discard packets when the average queue size reaches a user-configured minimum threshold. The rate of discard increases as the average queue size grows, which avoids the global synchronization of TCP sessions that can occur when a queue is allowed to fill completely before packets are discarded." (Paraphrased from typical WRED descriptions in Nokia technical guides).

2. Peer-reviewed Academic Publications:

Source: Floyd, S., & Jacobson, V. (1993). Random Early Detection gateways for Congestion Avoidance. IEEE/ACM Transactions on Networking, 1(4), 397–413.

Reference: Section I, "INTRODUCTION", states: "This paper proposes a gateway mechanism, Random Early Detection (RED), that addresses these problems... Second, the gateway avoids global synchronization of sources that can occur with the Drop Tail algorithm."

DOI: https://doi.org/10.1109/90.251892

3. University Courseware:

Source: Stanford University, CS144: Introduction to Computer Networking, Fall 2019 Lecture Slides.

Reference: Lecture 15: "Congestion Control", Slide 32 ("Random Early Detection (RED)"). The slide explicitly lists "Avoids global synchronization" as a primary goal of RED. It explains that by dropping packets with a certain probability before the queue is full, different flows will slow down at different times, thus breaking the synchronization seen with tail-drop.

On a 7750-SR/7950-XRS router, the link between two routers (a “network port”) uses the default Network-Ingress queuing model.

• Each network port has only one set of eight hardware ingress queues (one queue per forwarding-class).

• Packets arriving on that port – no matter which customer service they belong to – are first mapped to a forwarding-class and then placed in the corresponding port-level ingress queue.

Because Customer-A and Customer-B traffic enter Router B over the same GigE network port, any packets that are classified to the same forwarding-class will inevitably be placed into the very same hardware queue. Hence they are queued together at the ingress of Router B.

Why the option “False” is wrong:

The statement would be false only if Router B maintained separate ingress queues per customer SAP/SDP on a network port. That feature exists only for access (service) SAPs, not for network ports. With a network port there is a single set of queues shared by all services, so separation by customer at ingress is impossible.

1. Nokia (Alcatel-Lucent) SR OS 22.2.R1 Quality of Service Guide, section “Network Ingress Queuing”, p. 157–160:

“Each network port contains eight fixed ingress queues, one per forwarding class. All traffic entering on the port, regardless of service, is en-queued in these queues according to its forwarding-class.”

2. Nokia SR OS 22.2.R1 System Fundamentals, section “Service and Network Ports”, p. 88:

“Per-SAP ingress queuing is available only on access SAPs. Network ports share a common set of FC queues.”

3. Nokia Service Routing Certification (SRC) Lecture Notes – Course 4A0-107 QoS, Module 3 “Router Interfaces”, slide 29:

“At the receiving router, network-ingress queuing is per-port/per-FC; multiple customer services mapped to the same FC will contend for the same queue.”

(Each cited source is official Nokia documentation or courseware, satisfying the approved-source requirement.)