For feedback and comments: |
documentation.feedback@alcatel-lucent.com |
•
− PPPoE-capable interfaces can be created in a subscriber interface in both IES and VPRN services. Each SAP can support one or more PPPoE sessions depending on the configuration. A SAP can simultaneously have static hosts, DHCP leases and PPPoE sessions. The number of PPPoE sessions is limited per SAP, SLA profile or subscriber profile.If no authentication policy is assigned to the group interface or the pppoe-access-method is set to none, the local user database assigned to the PPPoE node under the group interface is queried either during the PADI phase or during the LCP authentication phase, depending on whether the match-list of the local user database contains the requirement to match on username. If the match-list does not contain the username option, PADI authentication will be performed and it is possible to specify an authentication policy in the local user database host for an extra RADIUS PAP-CHAP authentication point.The following attributes are sent to the RADIUS server for PPPoE authentication (optional attributes can be configured under the config>subscr-mgmt>auth-plcy>include-radius-attribute context):
•
•
• The matchlist for a local user database that is assigned directly to the PPPoE node under the group interface is always user-name, independent of the matchlist setting in the database.ATTRIBUTE Alc-SAP-Session-Index 180 integerThe intended use of the SAP session index is to provide the ability for PPPoE sessions to have their own set of queues (for QoS and accounting purposes) when using the same SLA profile name received from a RADIUS server. An example of this with multiple levels of HQoS egress scheduling is shown in Figure 25.Figure 25: Egress QoS per PPPoE Sessionconfigure subscriber-mgmt authentication-policy name
include-radius-attribute
[no] sap-session-indexFigure 26: Per PPPoE Session SLA Profile Selectionimport alcimport structfrom alc import radiusfrom alc import sub_svcPROXY_STATE = 33ALU = 6527SLA_PROF_STR = 13SAP_SESSION_INDEX = 180#################################### QoS for Multiple PPPoE Sessions# This script checks if a sap-session-index (sid) is included in the authentication# accept. If present, the sla-profile-string (sla) is adapted to "sla.sid"if alc.radius.attributes.isVSASet(ALU,SLA_PROF_STR):sla = alc.radius.attributes.getVSA(ALU,SLA_PROF_STR)if alc.radius.attributes.isVSASet(ALU,SAP_SESSION_INDEX):ssi = alc.radius.attributes.getVSA(ALU,SAP_SESSION_INDEX)suffix = "" .join(["%x" % ord(x) for x in ssi])alc.radius.attributes.setVSA(ALU,SLA_PROF_STR,sla + '.' + "%d" % int(suffix,16))
• Option 82 sub-option 13 (DHCP pool): This option indicates to the DHCP server that the address from the client should be taken from the specified pool. The local DHCP server will only honor this request if the use-pool-from-client option is given in the server configuration.
• When the config>service>vprn>sub-if>private-retail-subnets command is enabled on the subscriber interface, the node will not push the defined subnets in the retail context to the wholesale context. This allows IP overlap between PPPoE sessions. If an operator requires both residential and business services, two VPRNs connected to the same wholesaler can be created and use the flag in only one of them.Some CPEs use the network up-link in PPPoE mode and perform dhcp-server function for all ports on the LAN side. Instead of wasting one subnet for P2P uplink, CPEs use allocated subnet for LAN portion as shown in Figure 27.Figure 27: CPEs Network Up-link ModeNote: Unnumbered subscriber-interfaces are supported only for PPPoE, PPPoA and PPPoEoA (v4 and v6) hosts.Unnumbered does not mean that the subscriber hosts do not have an IP address or prefix assigned. It only means that the IP address range out of which the address or prefix is assigned to the host does not have to be known in advance via configuration under the subscriber-interface or subscriber-interface>ipv6 node.configurerouter/servicesubscriber-interface <name>ipv6[no] allow-unmatching-prefixesdelegated-prefix-length <bits>subscriber-prefixes
• However, the delegated-prefix-length (DPL) command is required. The DPL (or the length of the prefix assigned to each Residential Gateway) must be known in advance. All Residential Gateways (or subscribers) under the same subscriber-interface share this pre-configured DPL.
• In case that the assigned IP prefix/address (DHCPServer, RADIUS, LUDB) for the host falls outside of the CLI defined prefixes AND the allow-unmatching-prefixes command is configured, then the new address/prefix will be automatically installed in the FIB.Figure 28: Typical MLPPPoA DeploymentMLPPP header is primarily required for sequencing the fragments. But in case that a packet is not fragmented, it can be transmitted over the MLPPP bundle using either plain PPP encapsulation or MLPPP encapsulation. MLPPP encapsulation for fragmented traffic is shown in Figure 29.Figure 29: MLPPP EncapsulationMLPPPoX is negotiated during the LCP session negotiation phase by the presence of the Max-Received-Reconstructed Unit (MRRU) field in the LCP ConfReq. MRRU option is a mandatory field required in MLPPPoX negotiation. It represents the maximum number of octets in the Information field (Data part in Figure 29) of a reassembled packet. The MRRU value negotiated in the LCP phase must be the same on all member links and it can be greater or lesser than the PPP negotiated MRU value of each member link. This means that the reassembled payload of the PPP packet can be greater than the transmission size limit imposed by individual member links within the MLPPPoX bundle. Packets will always be fragmented so that the fragments are within the MRU size of each member link.
• bundle-mtu determines the maximum length of the original IP packet that can be transmitted over the entire bundle (collection of links) before any MLPPPoX processing takes place on the transmitting side. This is also the maximum size of the IP packet that the receiving node can accept once it de-encapsulates and assembles received MLPPPoX fragments of the same packet. Bundle-mtu is relevant in the context of the collection of links.
• link-mtu determines the maximum length of the payload before it is PPP encapsulated and transmitted over an individual link within the bundle. Link-mtu is relevant in the context of the single link within the bundle.LFI Case — When Interleave is enabled in a bundle, low priority packets will always be MLPPPoX encapsulated. If a low-priority packet’s length exceeds the internally calculated Fragment Length, the packet will be MLPPPoX fragmented and encapsulated. High priority packets whose length is smaller than the link-mtu will be PPP encapsulated and transmitted without MLPPP encapsulation.Non-LFI Case — When Interleave is disabled in a bundle, all packets will be MLPPPoX encapsulated. If a packet’s length exceeds the internally calculated fragment length, the packet will be MLPPPoX fragmented and encapsulated.There are two major tasks associated with LFI1 on the LNS:This entire process is further clarified by the five points (1-5) in the packet route from the LNS to the Residential Gateway (RG) as depicted in Figure 30.
3.
4.
5. Figure 30: Packet Route from the LNS to the RGHigh priority traffic within the bundle is classified into the high priority queue. This type of traffic is not MLPPPoX encapsulated unless its packet size exceeds the link MTU as described in MLPPPoX Fragmentation, MRRU and MRU Considerations . Low priority traffic is classified into a low priority queue and is always MLPPPoX encapsulated. In case that the high priority traffic becomes MLPPPoX encapsulated/fragmented, the MLPPPoX processing module (BB-ISA) will consider it as low-priority. The assumption is that the high priority traffic is small in size and consequently MLPPPoX encapsulation/fragmentation an degradation in priority can be avoided. The aggregate rate of the MLPPPoX bundle is on-the-wire rate of the last mile as shown in Figure 3.Figure 31: Last Mile EncapsulationIn Figure 30 (point 2) the first fragment F1 is sent out immediately (transmission delay at 10G is in the 1us range). The transmission of the next fragment F2 is delayed by 50ms. While the transmission of the second fragment F2 is being delayed, the two high priority packets (P1 and P2 in red) are received by the BB-ISA and are immediately transmitted ahead of fragments F2 and F3. This approach relies on the imperfection of the IOM shaper which is releasing traffic in bursts (P2 and P3 right after P1). The burst size is dependent on the depth of the rate token bucket associated with the IOM shaper.Note on the AN-RG link in Figure 30 that packets P2 and P3 are ahead of fragments F2 and F3. Therefore the delay incurred on this link by the low priority packets is never greater than the transmission delay of the first fragment (50ms). The remaining two fragments, F2 and F3, can be queued and further delayed by the transmission time of packets P2 and P3 (which is normally small, in our example 3ms for each).We will not support multiclass MLPPP (RFC 2686, The Multi-Class Extension to Multi-Link PPP). Multiclass MLPPP would require another level of intelligent queuing in the BB-ISA which we do not have.Figure 32: MLPPPoE — Multiple Physical LinksFigure 33: MLPPPoE — Single Physical LinkFigure 34: MLPPP(oE)oA — Multiple Physical LinksFigure 35: MLPPP(oE)oA — Single Physical LinkPPP/PPPoE sessions are by default load balanced across multiple BB-ISAs (max 6) in the same group. The load balancing algorithm considers the number of active session on each BB-ISA in the same group2.In a per fragment/packet load sharing algorithm, there is always the possibility that there is uneven load utilization between the member links. A single link overload will most likely go unnoticed in the network all the way to the Access Node. The access node is the only node in the network that actually has multiple physical links connected to it. All other session-aware nodes3 (LAC and LNS) only see MLPPPoX as a bundle with multiple sessions without any mechanism to shape traffic per physical link.
• PPPoE tags — Vendor Specific Tags (RFC 2516, A Method for Transmitting PPP Over Ethernet (PPPoE); tag type 0x0105; tag value is Enterprise Number 3561 followed by the TLV sub-options as specified in TR-101 -> Actual Data Rate Downstream 0x82)config>subscriber-management>sla-profile <name>egressreport-rate agg-rate-limit | scheduler <scheduler-name> | pppoe-actual-rate | rfc5515-actual-rate
• The priority of the forwarding class in regular QoS (on IOM) is determined by the properties4 of the queue to which the forwarding class is mapped. In contracts, traffic prioritization in LFI domain (in BB-ISA) is determined by the outer dot1p bits that are set by the carrier IOM while transmitting packets towards the BB-ISA. The outer dot1p bits are marked based on the forwarding class information determined by classification/re-classification on ingress/carrier IOM. This marking of outer dot1p bits in the Ethernet header between the carrier IOM and the BB-ISA is fixed and defined in the default sap-egress LNS ESM policy 65537. The marking definition is as follows:FC be -> dot1p 0FC l2 -> dot1p 1FC af -> dot1p 2FC l1 -> dot1p 3FC h2 -> dot1p 4FC ef -> dot1p 5FC h1 -> dot1p 6FC nc -> dot1p 7In LFI (on BB-ISA), dot1p bits [0,1,2 and 3] are considered low priority while dot1p bits (4,5,6 and 7) are considered high priority. Consequently, forwarding classes BE, L2, AF and L1 are considered low priority while forwarding classes H2, EF, H1 and NC are considered high priority. High priority traffic5 will be interleaved with low priority traffic.
•
• Figure 36: QoS Enforcement Points in the LNSL2TP traffic originated locally in LNS can be marked via the router/service vprn->sgt-qos hierarchy.
• The decision whether a new session should join an existing MLPPPoX bundle, or trigger creation of a new one is governed by RFC 1990, The PPP Multilink Protocol (MP), section 5.1.3, page 16, cases 1,2,3, and 4.
• From the LAC via Tx-Connect-Speed AVP or by standard L2TP encoding as described in the RFC 5515, Layer 2 Tunneling Protocol (L2TP) Access Line Information Attribute Value Pair (AVP) Extensions.ip-only type mirrors are supported on MLPPPoX bundles.