L2TP network server

In some cases, PPPoE clients do not honor the negotiated MRU during the LCP phase and consequently, they send packets larger than the negotiated MRU. This applies to control and data packets.

In this case, the LAC fragments IPv4 packets which then have to be reassembled in LNS.

In general, reassembly processing applies only to the end nodes that are receiving fragments. In tunneled environment a fragmented packet must be reassembled before it is de-encapsulated.

All traffic matching the criteria associated with the filter action reassemble is forwarded to the reassembly function, regardless of whether the traffic is fragmented or not.

In case that there are multiple ISAs in the NAT group, traffic is load shared between them based on the source IP address and the incoming service ID (routing context).

In case that an active ISA fails in a NAT group, the standby ISA takes over the reassembly function. However, the switchover is not stateful and consequently traffic destined for the failed ISA is lost until it is restarted.

The term MLPPPoX is used to reference MLPPP sessions over ATM transport (oA), Ethernet over ATM transport (oEoA) or Ethernet transport (oE). Although MLPPP in subscriber management context is not supported natively over PPP/HDLC links, the terms MLPPP and MLPPPoX terms can be used interchangeably. The reason for this is that link bundling, MLPPP encapsulation, fragmentation and interleaving can be in a broader scope observed independently of the transport in the first mile.

Terms speed and rate are interchangeably used throughout this section. Usually speed refers to the speed of the link in general context (high or low) while rate usually quantitatively describes the link speed and associates it with the specific value in b/s.

This functionality is supported through LNS on BB-ISA. LNS MLPPPoX can be used then as a workaround for PTA deployments, whereby LAC and LNS can be run back-to-back in the same system (connected via an external loop or a VSM2 module), and therefore locally terminate PPP sessions.

MLPPPoX can:

• Increase bandwidth in the last mile by bundling multiple links together.

• LFI/reassembly over a single MLPPPoX capable link (plain PPP does not support LFI).

After the MLPPP bundle is created in the 7750 SR, traffic can be transmitted by using MLPPP encapsulation. However, MLPPP encapsulation is not mandatory over an MLPPP bundle.

MLPPP 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.

MLPPPoX 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 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 are always be fragmented so that the fragments are within the MRU size of each member link.

Another field that could be optionally present in an MLPPPoX LCP Conf Req is an Endpoint Discriminator (ED). Along with the authentication information, this field can be used to associate the link with the bundle.

The last MLPPPoX negotiated option is the Short Sequence Number Header Format Option which allows the sequence numbers in MLPPPoX encapsulated frames/fragments to be 12-bit long (instead 24-bit long, by default).

After the multilink capability is successfully negotiated via LCP, PPP sessions can be bundled together over MLPPPoX capable links.

The basic operational principles are:

• LCP session is negotiated on each physical link with MLPPPoX capabilities between the two nodes.

• Based on the ED or the authentication outcome, a bundle is created. A subsequent IPCP negotiation is conveyed over this bundle. User traffic is sent over the bundle.

• If a new link tries to join the bundle by sending a new MLPPPoX LCP Conf Request, the LCP session is negotiated, authentication performed and the link is placed under the bundle containing the links with the same ED or authentication outcome.

• IPCP/IPv6CP is, in the whole process, negotiated only once over the bundle. This negotiation occurs at the beginning, when the first link is established and MLPPPoX bundle created. IPCP and IPv6CP messages are transmitted from the 7750 SR LNS without MLPPPoX encapsulation, while they can be received as MLPPPoX encapsulated or non-MLPPPoX encapsulated.

The lowest granularity at which MLPPPoX can be enabled is an L2TP tunnel. An MLPPPoX enabled tunnel is not limited to carrying only MLPPPoX sessions but can carry normal PPP(oE) sessions as well.

In addition to enabling MLPPPoX on the session terminating LNS node, MLPPPoX can also be enabled on the LAC via PPP policy. The purpose of enabling MLPPPoX on the LAC is to negotiate MLPPPoX LCP options with the client. When the LAC receives the MRRU option from the client in the initial LCP ConfReq, it changes its tunnel selection algorithm so that all sessions of an MLPPPoX bundle are mapped into the same tunnel.

The LAC negotiates MLPPPoX LCP options regardless of the transport technology connected to it (ATM or Ethernet). LCP negotiated options are passed by the LAC to the LNS via Proxy LCP in ICCN message. In this fashion the LNS has an option to accept the LCP options negotiated by the LAC or to reject them and restart the negotiation directly with the client.

The LAC transparently passes session traffic handed to it by the LNS in the downstream direction and the MLPPPoX client in the upstream direction. The LNS and the MLPPPoX client performs all data processing functions related to MLPPPoX such as fragmentation and interleaving.

When the LCP negotiation is completed and the LCP transition into an open state (configuration ACKs are sent and received), the Authentication phase on the LAC begins. During the Authentication phase, the L2TP options become known (L2TP group, tunnel, and so on), and the session is extended by the LAC to the LNS via L2TP. If the Authentication phase does not return L2TP options, the session is terminated because the 7750 SR does not support directly terminated MLPPPoX sessions.

If MLPPPoX is not enabled on the LAC, the LAC negotiates a plain PPP session with the client. If the client accepts plain PPP instead of MLPPPoX as offered by the LAC, when the session is extended to the LNS, the LNS renegotiates MLPPPoX LCP with the client on a MLPPPoX enabled tunnel. The LNS learns about the MLPPPoX capability of the client via proxy LCP message in ICCN (first Conf Req received from the client is also sent in the proxy LCP). If there is no indication of the MLPPPoX capability of the client, the LNS establishes a plain PPP(oE) session with the client.

The purpose of LFI is to ensure that short high priority packets are not delayed by the transmission delay of large low priority packets on slow links.

For example it takes ~150 ms to transmit a 5000 B packet over a 256 kb/s link, while the same packet is transmitted in only 40 us over a 1 G link (~4000 times faster transmission). To avoid delaying a high-priority packet waiting in the queue while a large packet is being transmitted, the large packet can be segmented into smaller chunks. The high-priority packet can then be interleaved with the smaller fragments. This approach significantly reduces the delay of high-priority packets.

The interleaving functionality is only supported on MLPPPoX bundles with a single link. If more than one link is added into an interleaving-capable MLPPPoX bundle, interleaving is internally disabled and the tmnxMlpppBundleIndicatorsChange trap is generated.

With interleaving enabled on an MLPPPoX enabled tunnel, the following session types are supported:

• multiple LCP sessions tied into a single MLPPPoX bundle

  This scenario assumes multiple physical links on the client side. Theoretically it would be possible to have multiple sessions running over the same physical link in the last mile. For example, two PPPoE sessions going over the same Ethernet link in the last mile. Whichever the case may be, the LAC/LNS is unaware of the physical topology in the last mile (single or multiple physical links). Interleaving functionality is internally disabled on such MLPPPoX bundles.

• a single LCP session (including dual stack) over the MLPPPoX bundle

  This scenario assumes a single physical link on the client side. Interleaving is supported on such single session MLPPPoX bundle as long as the conditions for interleaving are met. Those conditions are governed by the max-fragment-delay command and calculation of the fragment size as described in subsequent sections.

• an LCP session (including dual stack) over a plain PPP/PPPoE session

  This type of session is a regular PPP(oE) session outside of any MLPPPoX bundle and therefore its traffic is not MLPPPoX encapsulated.

Packets on an MLPPPoX bundle are MLPPPoX encapsulated unless they are classified as high priority packets when interleaving is enabled.

As mentioned in the previous section, LFI on LNS is implemented only on MLPPPoX bundles with a single LCP session.

There are two major tasks associated with LFI on the LNS:

• executing subscriber QoS in the carrier IOM based on the last mile conditions. The subscriber QoS rates are the last mile on-the-wire rates. After traffic is QoS conditioned, it is sent to the BB-ISA for further processing.

• fragmentation and artificial delay (queuing) of the fragments so that high priority packets can be injected in-between low priority fragments (interleaved). This operation is performed by the BB-ISA.

Most of this is also applicable to non-lfi case. The only difference between lfi and non-lfi is that there is no artificial delay performed in non-lfi case.

Examine an example to further clarify functionality of LFI. The options, conditions and requirements that are used in our example to describe the wanted behavior are the following:

• High priority packets must not be delayed for more than 50ms in the last mile because of the transmission delay of the large low priority packets. Considering that tolerated end-to-end VoIP delay must be under 150ms, limiting the transmission delay to 50ms on the last mile link is a reasonable choosing.

• The link between the LNS and LAC is 1 Gb/s Ethernet.

• The last mile link rate is 256 kb/s.

• Three packets arrive back-to-back on the network side of the LNS (in the downstream direction). The large 5000B low priority packet P1 arrives first, followed by two smaller high priority packets P2 and P3, each 100B in length. Packets P1, P2 and P3 can be originated by independent sources (PCs, servers, and so on.) and therefore can theoretically arrive in the LNS from the network side back-to-back at the full network link rate (10 Gb/s or 100 Gb/s).

• The transmission time on the internal 10G link between the BB-ISA and the carrier IOM for the large packet (5000B) is 4us while the transmission time for the small packet (100B) is 80ns.

• The transmission time on the 1G link (LNS->LAC) for the large packet (5000B) is 40us while the transmission time for the small packet (100B) is 0.8us.

• The transmission time in the last mile (256 kb/s) for the large packet is ~150 ms while the transmission time for the small packet on the same link is ~3 ms.

• Last mile transport is ATM.

To satisfy the delay requirement for the high priority packets, the large packets are fragmented into three smaller fragments. The fragments are carefully sized so that their individual transmission time in the last mile does not exceed 50ms. After the first 50ms interval, there is window of opportunity to interleave the two smaller high priority packets.

This entire process is further clarified by the five points (1-5) in the packet route from the LNS to the Residential Gateway (RG).

The five points are described in subsequent sections.

Fragmentation and interleaving is implemented on the originating end of the traffic. In other words, in the upstream direction the CPE (or RG) is fragmenting and interleaving traffic. There is no interleaving or fragmentation processing in the upstream direction in the 7750 SR. The 7750 SR is on the receiving end and is only concerned with the reassembly of the fragments arriving from the CPE. Fragments are buffered until the packet can be reconstructed. If all fragments of a packet are not received within a preconfigured timeframe, the received fragments of the partial packet are discarded (a packet cannot be reconstructed without all of its fragments). This time-out and discard is necessary to prevent buffer starvation in the BB-ISA. Two values for the time-out can be configured: 100ms and 1s.

Interleaving over MLPPPoX bundles with multiple links are not supported. However, fragmentation is supported.

To preserve packet order, all packets on an MLPPPoX bundle with multiple links are MLPPPoX encapsulated (monotonically increased sequence numbers).

We do 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.

MLPPPoE is the only session type in the last mile that is supported:

MLPPPoE can be a single physical link or multilink. The last mile encapsulation is Ethernet over copper (This could be Ethernet over VDSL or HSDSL). The access rates (especially upstream) are still limited by the xDSL distance limitation and therefore, interleaving is required on a slow speed single link in the last mile. It is possible that the last mile encapsulation is Ethernet over fiber (FTTH) but in this case, users would not be concerned with the link speed to the point where interleaving and link aggregation is required.

Finally, this is the slow link of the last mile, the reason why LFI is performed in the first place. Assuming that LFI played its role in the network as designed, by the time the transmission of one fragment on this link is completed, the next fragment arrives just in time for unblocked transmission. In between the two fragments, we can have one or more small high priority packets waiting in the queue for the transmission to complete.

We can see on the AN-RG link in Figure 2 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).

If many low priority packets were waiting in the queue, then they would have caused delay for each other and would have further delayed the fragments in transit from the LNS to the LAC. This condition is normally caused by bursts and it should clear itself out over time.

MLPPP(oEo)A can be a single physical link or multilink. The last mile encapsulation is ATM over xDSL.

Some other combinations are also possible (ATM in the last mile, Ethernet in the aggregation) but they all come down to one of the above models that are characterized by:

• Ethernet or ATM in the last mile.

• Ethernet or ATM access on the LAC.

• MLPPP/PPPoE termination on the LNS

PPP/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 group.

The load balancing algorithm does not take into account the number of queues consumed on the carrier IOM. Therefore a session can be refused if queues are depleted on the carrier IOM even though the BB-ISA may be lightly loaded in terms of the number of sessions that is hosting.

With MLPPPoX, it is important that multiple sessions per bundle be terminated on the same LNS BB-ISA. This can be achieved by per tunnel load balancing mode where all sessions of a tunnel are terminated in the same BB-ISA. Per tunnel load balancing mode is mandatory on LNS BB-ISAs that are in the group that supports MLPPPoX.

On the LAC side, all sessions in an MLPPPoX bundle are automatically assigned to the same tunnel. In other words an MLPPPoX bundle is assigned to the tunnel. There can be multiple tunnels created between the same pair of LAC/LNS nodes.

All downstream traffic on an MLPPPoX bundle with multiple links is always MLPPPoX encapsulated. Some traffic is fragmented and served in a octet oriented round robin fashion over multiple member links. However, fragments are never delayed in case that the bundle contains multiple links.

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 most likely goes 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 nodes (LAC and LNS) only see MLPPPoX as a bundle with multiple sessions without any mechanism to shape traffic per physical link. Other nodes in this case being 7750 SRs. Other vendors may have the ability to condition (shape) traffic per session.

If one of the member sessions is perpetually overloaded by the LNS, traffic is dropped in the last mile because the corresponding physical link cannot absorb traffic beyond its physical capabilities. This would have detrimental effects on the whole operation of the MLPPPoX bundle. To prevent this perpetual overloading of the member links that can be caused by per packet/fragment load balancing scheme, the load balancing scheme that takes into account the number of octets transmitted over each member link. The octet counter of a new link is initialized to the lowest value of any existing link counter. Otherwise the load balancing mechanism would show significant bias toward the new link until the byte counter catches up with the rest of the links.

The last mile rate information along with the encapsulation information is used for fragmentation (to determine the maximum fragment length) and interleaving (delaying fragments in the BB-ISA). In addition, the aggregate subscriber rate (aggregate rate limit) on the LNS is automatically adjusted based on the last mile link rate and the number of links in the MLPPPoX bundle.

• downstream data rate in the last mile

  The subscriber aggregate rates (aggregate rate limit) used in H-QoS on the carrier IOM and in the BB-ISA (for interleaving) must be wire based in the last mile. This rule applies equally to both, the LAC and LNS.

  The last mile on-the-wire rates of the subscriber can be submitted to the LAC and the LNS via various means. The following bullets describe how the last mile wire rates are passed to each entity:

• LAC

  The last mile link rate is taken via the following methods in the order of listed priority:

  1. LUDB (rate-down command under the host hierarchy in LUDB)

  2. RADIUS Alc-Access-Loop-Rate-Down VSA. Although this VSA is stored in the state of plain PPP(oE) sessions (MLPPPoX bundled or not), it is applicable only to MLPPPoX bundles.

  3. 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)

     As long as the link rate information is available in the LAC, it is always passed to the LNS in the ICRQ message using the standard L2TP encoding. This cannot be disabled.

     In addition, an option is available to control the source of the rate information can be conveyed to the LNS via TX Connect Speed AVP in the ICCN message. This can be used for compatibility reasons with other vendors that can only use TX Connect Speed to pass the link rate information to the LNS. By default, the maximum port speed (or the sum of the maximum speeds of all member ports in the LAG) is reported in TX Connect Speed. Unlike the rate conveyed in ICRQ message, the TX Connect Speed content is configurable via the following command:

     • MD-CLI

       configure subscriber-mgmt sla-profile egress report-rate agg-rate
       configure subscriber-mgmt sla-profile egress report-rate policer
       configure subscriber-mgmt sla-profile egress report-rate pppoe-actual-rate
       configure subscriber-mgmt sla-profile egress report-rate rfc5515-actual-rate
       configure subscriber-mgmt sla-profile egress report-rate scheduler

     • classic CLI

       configure subscriber-mgmt sla-profile egress report-rate agg-rate-limit
       configure subscriber-mgmt sla-profile egress report-rate policer
       configure subscriber-mgmt sla-profile egress report-rate pppoe-actual-rate
       configure subscriber-mgmt sla-profile egress report-rate rfc5515-actual-rate
       configure subscriber-mgmt sla-profile egress report-rate scheduler

     The report-rate configuration option dictates which rate is reported in the TX Connect Speed as follows:

     • aggregate rate limit ‒ statically configured aggregate rate limit value or RADIUS QoS override is reported

     • scheduler ‒ virtual schedulers are not supported in MLPPPoX

     • policer ‒ rate taken from the policer with the specified ID

     • PPPoE actual rate ‒ rate taken from PPPoE Tags are reported. Rate reported via RFC5515 can still be different if the source for both methods is not the same

     • RFC 5515 actual speed ‒ the rate is taken from RFC 5515

     The RFC 5515 relies on the same encoding as PPPoE tags (vendor ID is ADSL Forum and the type for Actual Data Rate Downstream is 0x82). The two methods of passing the line rate to the LNS are using different message types (ICRQ and ICCN).

     The LAC on the 7750 SR is not aware of MLPPPoX bundles. As such, the aggregate subscriber bandwidth on the LAC is configured statically via usual means (sub-profile, scheduler-policy) or dynamically modified via RADIUS. The aggregate subscriber (or MLPPPoX bundle) bandwidth on the LAC is not automatically adjusted according to the rates of the individual links in the bundle and the number of the links in the bundle. As such, a user must ensure that the statically provided rate value for aggregate rate limit is the sum of the bandwidth of each member link in the MLPPPoX bundle. The number of member links and their bandwidth must be therefore known in advance. The alternative is to have the aggregate rate of the MLPPPoX bundle set to a high value and rely on the QoS treatment performed on the LNS.

• LNS

  The sources of information for the last mile link rate on the LNS are taken in the following order:

  1. LUDB (during user authentication phase, same as in LAC)

  2. RADIUS (same as in LAC)

  3. ICRQ message, Actual Data Downstream Rate (RFC 5515)

  4. ICCN message, TX Connect Speed

  There is no configuration option to determine the priority of the source of information for the last mile link rate. TX Connect Speed in ICCN message is only taken into consideration as a last resort in absence of any other source of last mile rate information.

  After the last mile rate information is obtained, the subscriber aggregate rate (aggregate rate limit) is automatically adjusted to the minimum value of:

  • the smallest link speed in the MLPPPoX bundle multiplied by the number of links in the bundle

  • statically configured aggregate-rate-limit

  The link speed of each link in the bundle must be the same, that is, different link speeds within the bundle are not supported. In the case that we receive different link speed values for last mile links within the bundle, we adopt the minimum received speed and apply it to all links.

  In case that the obtained rate information from the last mile for a session within the MLPPP bundle is out of bounds (1 kb/s to 100 Mb/s), the session within the bundle is terminated.

• encapsulation

  Wire-rates are dependent on the encapsulation of the link to which they apply. The last mile encapsulation information can be extracted via various means.

• LAC

  • static configuration via LUDB

  • RADIUS (Alc-Access_Loop-Encap-Offset VSA)

  • PPPoE tags; Vendor Specific Tags (RFC 2516; 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).

  The LAC passes the line encapsulation information to the LNS via ICRQ message using the encoding defined in the RFC 5515.

• LNS

  The LNS extracts the encapsulation information in the following order:

  • static configuration via LUDB

  • RADIUS (Alc-Access-Loop-Encap-Offset VSA)

  • ICRQ message (RFC 5515)

  In case that the encapsulation information is not provided by any of the existing means (LUDB, RADIUS, AVP signaling, PPPoE Tags), then by default PPPoA-null encapsulation is in effect. This applies to LAC and LNS.

The link failure in the last mile is detected via the expiration of session keepalives (LCP). The LNS tears down the session over the failed link and notify the LAC via a CDN message.

CoA request for the subscriber aggregate-rate-limit change is honored on the LAC and the LNS.

CoA for the rate change of an individual link within the bundle is supported through the same VSA that can be used to initially assign the rate to each member link. This is supported only on LNS. The rate override via CoA is applied to all active link members within the bundle.

Change of the access link options via CoA is be supported in the following fashion:

• Change of access loop encap: refused (NAK)

• Change of access loop rate down:

• On L2TP LAC session: refused (NAK)

  On LAC the access loop rate down is not locally used for any rate limiting function but instead it is just passed to the LNS at the beginning when the session is first established. Mid-session changes on LAC via CoA are not propagated to the LNS.

• On L2TP LNS session: Plain session: ignored

  The rate is stored in the MIB table but no rate limiting action is taken. In other words, this option is internally excluded from rate calculations and advertisements. However, it is shown in the output of the relevant show commands.

• Bundle session: applied on all link sessions

  The aggregate rate limit of the bundle is set to the minimum of the:

• CoA obtained local loop down rate multiplied by the number of links in the bundle

• aggregate rate limit configured statically or obtained via CoA

• Fragment length affected by this change.

  If interleaving is enabled on a single link bundle, the interleave interval is affected.

• Non-L2TP: ignored.

  The rate is stored in the MIB table but no rate limiting action is taken. In other words, this option is internally excluded from rate calculations and advertisements. However, it is shown in the output of the relevant show commands.

Similar behavior is exhibited if at mid-session, the options are changed via LUDB with the exception of the rate-down command in LAC. If this option is changed on the LAC, all sessions are disconnected.

On the LNS, accounting counters include all packet overhead (wire overhead from the last mile). There is only one accounting session per bundle.

On the LAC, there is one accounting session per PPPoE session (link).

In tunnel-accounting mode, there is one accounting session per link.

On LNS only, the stop-link of the last link of the bundle carries all accounting data for the bundle.

Filters and mirrors (LI) are not supported on an MLPPPoX bundle on LAC. However, filters and IP-only mirror type are supported on the LNS.

Locally terminated MLPPPoX (PTA) solution is offered based on the LAC and the LNS hosted in the same system. An external loop (or VSM2) is used to connect the LAC to the LNS within the same box. The subscribers are terminated on the LNS.

• sub-profile

  In the MLPPPoX case on LNS, multiple sessions are tied into the same subscriber aggregate rate limit via a subscriber profile. The consequence is that the aggregate rate of the subscriber can be adjusted dynamically depending on the advertised link speed in the last mile and the number of links in the bundle. Shaping in the LNS is performed per the entire MLPPPoX bundle (subscriber) instead of per individual member links within the bundle. The exception is obviously a MLPPPoX bundle with the single member link (interleaving case) where the relationship between the session and the MLPPPoX bundle is 1:1.

  In the LAC, the subscriber aggregate rate cannot be dynamically changed based on the number of links in the bundle and their rate. The LAC has no notion of MLPPPoX bundles. However, multiple sessions that in reality belong to an MLPPPoX bundle under the subscriber are shaped as an aggregate (aggregate rate limit under the sub-profile). This in essence yields the same shaping behavior as on LNS.

• sla-profile

  Sessions within the MLPPPoX bundle in LNS share a single subscriber-level agreement (SLA) profile instances (queues).

  In the LAC, as long as the sessions within the subscriber are on the same SAP, they can also share the same SLA profile. This is the case in MLPPPoX.

  The manner in which subscriber and SLA profiles are applied to MLPPPoX bundles and the individual sessions within, results in aggregate shaping per MLPPPoX bundle, as well as allocation of a unique set of queues per MLPPPoX bundle. This is valid irrespective of the location where shaping is executed (LAC or LNS).

  Note: Other vendors may implement per-session shaping within the bundle, which must be taken into consideration during a migration process.

• LAC behavior

  1. A new PPP(oEoA) session request arrives on the LAC (PADI or LCP Conf Req).

  2. The LAC negotiates PADx session if applicable.

  3. The LAC may negotiate MLPPPoX LCP phase with its own endpoint discriminator, or it may reject MLPPPoX specific options in LCP if MLPPPoX on the LAC is disabled with the following command:

     • MD-CLI

       configure subscriber-mgmt ppp-policy mlppp accept-mrru false
       

     • classic CLI

       configure subscriber-mgmt ppp-policy mlppp no accept-mrru

     If MLPPPoX options (seq num header format, ED, MRRU) are rejected, the assumption is that the client renegotiates plain PPP(oEoA) session with the LAC.

  4. When LCP (MLPPPoX capable or not) is negotiated, the session is authenticated (PAP/CHAP).

  5. On successful authentication, an L2TP tunnel is identified to which the session belongs.

  6. If the session is a non-L2TP session (PTA MLPPPoX capable session for which the tunnel cannot be determined), the session is terminated.

  7. Otherwise, the QoS constructs are created for the subscriber hosts: the session is assigned to a sub/sla-profiles.

  8. The session LCP options are sent to the LNS via call management messages.

  9. If another LCP session is requested on the same bundle, the LAC creates a new LCP session and join this session to the existing subscriber as another host. In other words, the LAC is bundle agnostic and the two sessions appear as two hosts under the same subscriber.

• LNS behavior

  The following assumes that MLPPPoX is configured on the LNS under the L2TP group or the tunnel hierarchy.

  • The LNS has the option to accept the LCP options or to reject them and start renegotiating LCP options directly with the client.

  • If the LNS choose to renegotiate LCP options with the client directly, this renegotiation is completely transparent to the LAC by the means of a T-bit (control vs. data) in the L2TP header. LCP is renegotiated on the LNS with all the options necessary to support MLPPPoX. Endpoint Discriminator is not mandatory in the MLPPPoX negotiation. If the client rejects it, the LNS must still be able to negotiate MLPPPoX capable session (same is valid for the LAC). If the client’s endpoint discriminator is invalid (bad format, invalid class, and so on), the 7750 SR does not negotiate MLPPPoX and instead a plain PPP session is created.

  • If the LNS is configured to accept the LCP Proxy options, the LNS determines the capability of the client.

  If there is no indication of MLPPPoX capability in the Proxy LCP (not even in the original ConfReq), the LNS may accept plain (non MLPPPoX capable) LCP session or renegotiate from scratch the non MLPPPoX capable session.

  If there is an indication of MLPPPoX capability in the Proxy LCP (either completely negotiated on the LAC or at least attempted from the client), the LNS tries to either accept the MLPPPoX negotiated session by the LAC or renegotiate the MLPPPoX capable session directly with the client.

  If the LCP Proxy options with MLPPPoX capability are accepted by the LNS, then the endpoint as negotiated on the LAC is also accepted.

  • After the MLPPPoX capable LCP session is negotiated or accepted, authentication can be performed on the LNS. Authentication on the LNS can be restarted (CHAP challenge/response with the client), or accepted (chap challenge/response accepted and verified by the LNS via RADIUS).

  • If the authentication is successful, depending on the evaluation of the options negotiated up to this point, a new MLPPPoX bundle is created or an existing MLPPPoX bundle is joined. In case that a new bundle is established, the QoS constructs for the subscriber(-host) are created (sub/sla-profile). Session negotiation advances to IPCP phase.

  • 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.

  • Interleaving is supported only on MLPPPoX bundles with single session in them.

• IPv6 is supported.

• AA is supported at LNS where full IP packets can be redirected via AA policies.

• Intra-chassis redundancy is supported:

  • CPM (stateful failover)

  • BB-ISA (non-stateful failover)