6. Internet Enhanced Service

This chapter provides information about Internet Enhanced Service (IES), used to provide IP routing services; that is, direct forwarding of IP traffic between CE devices, and also to facilitate the transport of in-band management datagrams of the 7705 SAR over ATM links.

Internet Enhanced Services can coexist with IES management SAP services on the same 7705 SAR node. IP over ATM is used exclusively for in-band management of the 7705 SAR. Up to two IPoATM SAPs can be bound to IES along with many other SAPs with other (non-ATM) supported SAP encapsulation types. Traffic from IPoATM SAPs is extracted to the CSM for further processing. Traffic received from other IES SAPs is forwarded as per the forwarding table (FIB).

Topics in this chapter include:

  1. IES for In-band Management
  2. IES for Customer Traffic
  3. Configuring IES with CLI
  4. IES Command Reference

6.1. IES for In-band Management

Topics in this section include:

  1. Setting Up Connections Between the NSP NFM-P and the 7705 SAR
  2. Encapsulation
  3. Layer 2 and Layer 3 Traffic Management
  4. Troubleshooting and Fault Detection Services
  5. IP ECMP Load Balancing

In the HSDPA offload application (see HSDPA Offload), the main uplink out of a typical cell site is over the ATM network using leased lines. Mission-critical traffic such as voice, signaling, and synchronization traffic is carried over the ATM network.

Internet Enhanced Service (IES) provides a reliable means of diverting the node management IP packets from the DSL IP network to the more reliable Layer 2 ATM network. To do this, IES provides an IP address and interworking function between the Layer 3 IP network and the Layer 2 ATM network. Without this capability, the in-band IP management traffic for the 7705 SAR could only be connected to an IP network.

IES can be used for in-band management of the 7705 SAR over the ATM network. IP over an ATM SAP bound to IES is for in-band management purposes only, and IP traffic from the ATM SAP is only extracted to the CSM; it is not forwarded.

IES management service is supported on the following cards for the 7705 SAR-8 and 7705 SAR-18:

  1. 16-port T1/E1 ASAP Adapter card
  2. 32-port T1/E1 ASAP Adapter card

IES management service is also supported on the T1/E1 ports on the following:

  1. 7705 SAR-M (variants with T1/E1 ports)
  2. 7705 SAR-A (variants with T1/E1 ports)
  3. 7705 SAR-X
  4. 4-port T1/E1 and RS-232 Combination module

The service can be created on an ATM port or on an IMA group.

In the 7705 SAR, all traffic received over IES management SAPs is extracted directly to the control plane (CSM) in the same way as management traffic received over the CSM console port or Ethernet management port, or management traffic destined for the 7705 SAR over an Ethernet or MLPPP encapsulated network port. With IES management, the traffic transported is always IP packets. At the termination point of the ATM link, the IP packets are extracted to the CSM for further processing.

6.1.1. Setting Up Connections Between the NSP NFM-P and the 7705 SAR

IP over ATM is used for in-band management of the 7705 SAR. This requires the use of IP addresses so that the packets can be routed through the network using a routing table to indicate the next hop. Because Apipe interfaces (SAPs) do not have IP addresses, Apipes cannot be used to carry the management traffic.

With IES, the ATM SAP can be used for the forwarding of management IP packets. To set up a connection, IES is enabled on an interface on the 7705 SAR and the IP address for the interface is defined. A PVCC connection is then set up between the 7705 SAR and the remote router (SR) attached to the network manager (NSP NFM-P).

The IP datagrams are encapsulated into AAL5 for transport over the ATM network.

At the remote SR end, the SAP is bound to a VPRN instance to ensure that LDP signaling to the system IP address of the 7705 SAR flows through the IP/GRE link and not over the ATM link. Within the VPRN, an IP address is assigned at the termination SAP. The IP datagram is extracted from the ATM cell at this termination point and is routed to the NSP NFM-P.

Alternatively, manually configured connections can be used instead of signaled pseudowires.

Note:

The remote IP address must be manually configured and a static route must be set up between the two connections. This configuration is beyond the scope of this document; refer to the 7705 SAR Router Configuration Guide for information.

For redundancy, it is recommended that two VCs be configured per ATM port or IMA group. This requires the configuration of two static routes. ECMP must be enabled to allow duplicate routes in the routing table, and BFD can be enabled to trigger a faster handoff to the other route in case of route failure.

6.1.2. Encapsulation

To run IP traffic over ATM links, the system uses routed VC-mux encapsulation as specified in RFC 2684, Multiprotocol Encapsulation over ATM Adaptation Layer 5. Since the only supported Layer 3 protocol over the management VC is IP, the VC mux encapsulation method is implemented to reduce complexity and overhead; likewise, routing mode is preferred over bridged mode.

The maximum MTU size supported is 2048 bytes.

6.1.3. Layer 2 and Layer 3 Traffic Management

ATM traffic descriptors can be applied at the ingress (policing) and egress (shaping and service category scheduling and prioritization) of the IES SAP in order to provide traffic management functions at Layer 2.

Management IP traffic that is destined for the CSM is classified at Layer 3 and is forwarded into the fabric from one of three of the adapter card control queues:

  1. high priority
  2. low priority
  3. FTP priority

The high-priority and low-priority queues are limited to 1 Mb/s and the FTP queue is rate-limited to 3 Mb/s ingress to the fabric toward the control plane.

Note:

Proper configuration of the traffic descriptor profiles is essential for proper operation of the IES SAP. If no profile is assigned, the default UBR service category is assumed. All IES 7705 SAR traffic is scheduled; no shaping is supported in this mode. To ensure that IP traffic transported over the IES SAP is prioritized fairly, ATM layer traffic descriptors should be assigned. See IES Management SAP Commands in the IES Command Reference section for information.

6.1.4. Troubleshooting and Fault Detection Services

The IES in-band management service supports ATM OAM F4 (VP level) and F5 (VC level) cell generation and termination. For more information on OAM, refer to the 7705 SAR OAM and Diagnostics Guide, “OAM and SAA”.

Bidirectional forwarding detection (BFD) can also be configured on the IES interface. BFD is a simple protocol for detecting failures in a network. BFD uses a “hello” mechanism that sends control messages periodically to the far end and receives periodic control messages from the far end. BFD is implemented for IGP and BGP protocols, including static routes, in asynchronous mode only, meaning that neither end responds to control messages; rather, the messages are sent in the time period configured at each end.

To support redundancy, ECMP must be enabled to allow duplicate routes in the routing table, and BFD must be enabled to trigger the handoff to the other route in case of failure.

Due to the lightweight nature of BFD, it can detect failures faster than other detection protocols, making it ideal for use in applications such as mobile transport.

If the configured number of consecutive missed BFD messages is reached, the route to the peer is declared not active.

Note:

Layer 2 AIS/RDI cells that are received on the IES SAP will disable the IP interface. Link failures detected by BFD will also disable the IP interface.

6.1.5. IP ECMP Load Balancing

IP ECMP allows the configuration of load balancing across all IP interfaces at the system level or interface level on the network side. Layer 4 port attributes and the TEID attribute in the hashing algorithm can be configured with the l4-load-balancing and teid-load-balancing commands in the config>service>ies> interface context. Configuration of the l4-load-balancing command at the interface level overrides the system-level settings for the specific interface. The teid-load-balancing command can only be configured at the interface level.

The system IP address can be included in or excluded from the hashing algorithm with the system-level system-ip-load-balancing command.

For more information on IP ECMP, refer to the 7705 SAR Router Configuration Guide, “Static Routes, Dynamic Routes, and ECMP”.

6.2. IES for Customer Traffic

Topics in this section include:

  1. DHCP Relay and DHCPv6 Relay
  2. IPCP
  3. IPSec Support
  4. Security Zones and IES
  5. Proxy ARP
  6. Configurable ARP Retry Timer
  7. Unnumbered Interfaces
  8. Troubleshooting and Fault Detection Services
  9. VRRP on IES Interfaces
  10. SAPs
  11. Spoke SDP Termination to IES
  12. Bandwidth Optimization for Low-speed Links

IES provides IP connectivity between customer access points. From the customer’s perspective, IES provides a direct IP connection and can be used for Internet connectivity, as shown in Figure 96. The customer is assigned an IP interface and a SAP is associated with the IP interface to designate a customer access point to the service—one SAP per interface. SAPs can be MC-MLPPP, PPP/MLPPP, LAG, or null/dot1q/qinq Ethernet. SDPs are not required, because traffic is routed rather than being encapsulated in a tunnel.

Figure 96:  IES for Customer Access to the Internet 

IES supports static routes on customer IP interfaces (that is, SAPs). These routes are redistributed into the global routing table of the 7705 SAR.

IES is supported on the following:

  1. the 16-port T1/E1 ASAP Adapter card
  2. the 32-port T1/E1 ASAP Adapter card
  3. the Packet Microwave Adapter card
  4. any T1/E1 port on the 7705 SAR-M (variants with T1/E1 ports)
  5. any T1/E1 port on the 7705 SAR-A (variants with T1/E1 ports)
  6. any T1/E1 port on the 4-port T1/E1 and RS-232 Combination module
  7. any port on the 8-port Ethernet Adapter card
  8. any port on the 6-port Ethernet 10Gbps Adapter card
  9. any port on the 8-port Gigabit Ethernet Adapter card
  10. any port on the 10-port 1GigE/1-port 10GigE X-Adapter card (10-port 1GigE mode)
  11. any port on the 4-port SAR-H Fast Ethernet module
  12. any port on the 6-port SAR-M Ethernet module
  13. any Ethernet port on the 7705 SAR-M (all variants)
  14. any Ethernet port on the 7705 SAR-A (both variants)
  15. any Ethernet port on the 7705 SAR-Ax
  16. any Ethernet port on the 7705 SAR-W
  17. any Ethernet port on the 7705 SAR-Wx (all variants)
  18. any Ethernet port on the 7705 SAR-H
  19. any Ethernet port on the 7705 SAR-Hc
  20. any Ethernet port on the 7705 SAR-X
  21. GPON module ports and DSL module ports when the module is installed in the 7705 SAR-M (variants with module slots)

Ports must be in access mode.

The encapsulation type for Ethernet ports must be null, dot1q, or qinq. The encapsulation type for DSL and GPON module ports on the 7705 SAR-M must be null or dot1q; however, the encapsulation type on a DSL port on the 7705 SAR-Wx can be null, dot1q, or qinq.

IES IPv6 SAPs are supported on the following cards, modules, and ports:

  1. the 8-port Ethernet Adapter card (version 2 only)
  2. the 6-port Ethernet 10Gbps Adapter card
  3. the 8-port Gigabit Ethernet Adapter card
  4. the 10-port 1GigE/1-port 10GigE X-Adapter card (10-port 1GigE mode)
  5. the Packet Microwave Adapter card
  6. the 4-port SAR-H Fast Ethernet module
  7. the 6-port SAR-M Ethernet module
  8. any Ethernet port on the 7705 SAR-M (all variants)
  9. any Ethernet port on the 7705 SAR-A (both variants)
  10. any Ethernet port of the 7705 SAR-Ax
  11. the 7705 SAR-W
  12. any Ethernet port on the 7705 SAR-Wx (all variants)
  13. the 7705 SAR-H
  14. any Ethernet port on the 7705 SAR-Hc
  15. any Ethernet port of the 7705 SAR-X
  16. GPON module ports and DSL module ports when the module is installed in the 7705 SAR-M (variants with module slots)

For more information on IPv6 addressing, refer to the 7705 SAR Router Configuration Guide, “Internet Protocol Versions”.

More than one Internet Enhanced Service can be created for a single customer ID, and more than one IP interface can be created within a single IES. All IP interfaces created within an IES belong to the same customer.

The service provider applies billing, ingress/egress shaping and policing to the customer.

Note:

  1. Internet Enhanced Services require that the fabric mode be set to aggregate mode rather than per-destination mode. IES is only supported with aggregate-mode fabric profiles. If the fabric mode is set to per-destination mode, creation of the Internet Enhanced Service is blocked through the CLI. The fabric mode must be changed to aggregate mode before IES can be configured. As well, if IES is configured, alteration of the fabric mode is blocked.
  2. For information on configuring fabric mode, refer to the 7705 SAR Quality of Service Guide, “Configurable Ingress Shaping to Fabric (Access and Network)”.

6.2.1. DHCP Relay and DHCPv6 Relay

The 7705 SAR provides DHCP/BOOTP Relay agent services and DHCPv6 Relay agent services for DHCP clients. DHCP is used for IPv4 network addresses and DHCPv6 is used for IPv6 network addresses. Both DHCP and DHCPv6 are known as stateful protocols because they use dedicated servers to maintain parameter information.

Unless stated otherwise, DHCP is equivalent to “DHCP for IPv4”, or DHCPv4.

In the stateful autoconfiguration model, hosts obtain interface addresses and/or configuration information and parameters from a server. The server maintains a database that keeps track of which addresses have been assigned to which hosts.

The 7705 SAR supports DHCP Relay on access IP interfaces associated with IES and VPRN and on network interfaces. Each DHCP instance supports up to eight DHCP servers.

The 7705 SAR supports DHCPv6 Relay on access IP interfaces associated with IES and VPRN. Each DHCPv6 instance supports up to eight DHCPv6 servers.

Note:

  1. The 7705 SAR acts as a Relay agent for DHCP and DHCPv6 requests and responses, and can also be configured to function as a DHCP or DHCPv6 server. DHCPv6 functionality is only supported on network interfaces and on access IP interfaces associated with VPRN.
  2. When used as a CPE, the 7705 SAR can act as a DHCP client to learn the IP address of the network interface. Dynamic IP address allocation is supported on both network and system interfaces.
  3. For more information on DHCP and DHCPv6, refer to the 7705 SAR Router Configuration Guide, “DHCP and DHCPv6”.

6.2.1.1. DHCP Relay

The 7705 SAR provides DHCP/BOOTP Relay agent services for DHCP clients. DHCP is a configuration protocol used to communicate network information and configuration parameters from a DHCP server to a DHCP-aware client. DHCP is based on the BOOTP protocol, with additional configuration options and the added capability of allocating dynamic network addresses. DHCP-capable devices are also capable of handling BOOTP messages.

A DHCP client is an IP-capable device (typically a computer or base station) that uses DHCP to obtain configuration parameters such as a network address. A DHCP server is an Internet host or router that returns configuration parameters to DHCP clients. A DHCP/BOOTP Relay agent is a host or router that passes DHCP messages between clients and servers.

Home computers in a residential high-speed Internet application typically use the DHCP protocol to have their IP address assigned by their Internet service provider.

The DHCP protocol requires the client to transmit a request packet with a destination broadcast address of 255.255.255.255 that is processed by the DHCP server. Since IP routers do not forward broadcast packets, this would suggest that the DHCP client and server must reside on the same network segment. However, for various reasons, it is sometimes impractical to have the server and client reside in the same IP network. When the 7705 SAR is acting as a DHCP Relay agent, it processes these DHCP broadcast packets and relays them to a preconfigured DHCP server. Therefore, DHCP clients and servers do not need to reside on the same network segment.

DHCP OFFER messages are not dropped if they contain a yiaddr that does not match the local configured subnets on the DHCP relay interface. This applies only to regular IES and VPRN interfaces with no lease-populate configured on the DHCP relay interface.

6.2.1.1.1. DHCP Options

DHCP options are codes that the 7705 SAR inserts in packets being forwarded from a DHCP client to a DHCP server. Some options have additional information stored in suboptions.

The 7705 SAR supports the Relay Agent Information Option 82 as specified in RFC 3046. The following suboptions are supported:

  1. circuit ID
  2. remote ID
  3. vendor-specific options

6.2.1.2. DHCPv6 Relay

DHCPv6 Relay operation is similar to DHCP in that servers send configuration parameters such as IPv6 network addresses to IPv6 nodes, but DHCPv6 Relay is not based on the DHCP or BOOTP protocol. DHCPv6 can be used instead of stateless autoconfiguration (refer to the 7705 SAR Router Configuration Guide, “Neighbor Discovery”) or in conjunction with it.

DHCPv6 is also oriented around IPv6 methods of addressing, especially the use of reserved, link-local scoped multicast addresses. DHCPv6 clients transmit messages to these reserved addresses, allowing messages to be sent without the client knowing the address of any DHCP server. This transmission allows efficient communication even before a client has been assigned an IP address. When a client has an address and knows the identity of a server, it can communicate with the server directly using unicast addressing.

The DHCPv6 protocol requires the client to transmit a request packet with a destination multicast address of ff02::1:2 (all DHCP servers and relay agents on the local network segment) that is processed by the DHCP server.

Similar to DHCP address allocation, if a client needs to obtain an IPv6 address and other configuration parameters, it sends a Solicit message to locate a DHCPv6 server, then requests an address assignment and other configuration information from the server. Any server that can meet the client’s requirements responds with an Advertise message. The client chooses one of the servers and sends a Request message, and the server sends back a Reply message with the confirmed IPv6 address and configuration information.

If the client already has an IPv6 address, either assigned manually or obtained in some other way, it only needs to obtain configuration information. In this case, exchanges are done using a two-message process. The client sends an Information Request message, requesting only configuration information. A DHCPv6 server that has configuration information for the client sends back a Reply message with the information.

The 7705 SAR supports the DHCPv6 Relay Agent option in the same way that it supports the DHCP Relay Agent option. This means that when the 7705 SAR is acting as a DHCPv6 Relay Agent, it relays messages between clients and servers that are not connected to the same link.

6.2.1.2.1. DHCPv6 Options

DHCPv6 options are codes that the 7705 SAR inserts in packets being forwarded from a DHCPv6 client to a DHCPv6 server. DHCPv6 supports interface ID and remote ID options as defined in RFC 3315, Dynamic Host Configuration Protocol for IPv6 (DHCPV6) and RFC 4649, DHCPv6 Relay Agent Remote-ID Option.

6.2.2. IPCP

Similar to DHCP over Ethernet interfaces, Internet Protocol Control Protocol (IPCP) extensions to push IP information over PPP/MLPPP IES SAPs are supported. Within this protocol, extensions can be configured to define the remote IP address and DNS IP address to be signaled via IPCP on the associated PPP interface. The IPCP-based IP and DNS assignment process is similar to DHCP behavior; IPCP-based IP/DNS assignment uses PPP/MLPPP IP layer protocol handshake procedures. PPP/MLPPP connected devices hooked up to IES can benefit from this feature for the assignment of IP and DNS to the associated interface.

6.2.3. IPSec Support

The 7705 SAR supports IPSec and IPSec tunnels, where IES is used as a public (untrusted) network-facing service and VPRN is used as a private (trusted) network-facing service. IES interfaces support the provisioning of tunnel SAPs as part of IPSec provisioning. The sap-id for a tunnel SAP is tunnel-1.public:tag.

For more information, see the IPSec chapter in this guide.

6.2.4. Security Zones and IES

The 7705 SAR supports a number of mechanisms for node security, including Access Control Lists (ACLs), Network Address Translation (NAT), and stateful, zone-based firewalls. For information about ACLs, NAT, and firewalls, refer to the 7705 SAR Router Configuration Guide, “Configuring Security Parameters”.

NAT and firewall security configurations are both based on zones. Zones segment a network, making it easier to control and organize traffic. A zone consists of a group of Layer 3 interfaces with common criteria, bundled together. Security policies, which define a set of rules that determine how NAT or firewall should direct traffic, can be applied to the entire zone or to multiple zones. To enable NAT or firewall functionality, security policy and profile parameters must be configured under the config>security context in the CLI, and a security zone must be configured under one or more of the following contexts:

  1. config>router>zone
  2. config>service>vprn>zone
  3. config>service>ies>zone

A zone is created by adding at least one Layer 3 interface to the zone configuration. Multiple zones can be created within each service or within the router context. Layer 3 interfaces from different services cannot be grouped into a single common zone. Table 91 lists the supported interfaces that can be added to zones in each CLI context for NAT or firewall.

Table 91:   Security Zone Interfaces per Context 

CLI Context

Interface Type

NAT

Firewall

Router

Layer 3

✓

✓

VPRN

SAP

✓

✓

Spoke-SDP termination

✓

✓

IPSec private

Routed VPLS

✓

✓

IES

SAP

✓

✓

Spoke-SDP termination

✓

✓

IPSec public

✓

Routed VPLS

✓

✓

6.2.5. Proxy ARP

Proxy ARP is supported on IES interfaces.

Proxy ARP is a technique by which a router on one network responds to ARP requests intended for another node that is physically located on another network. The router effectively pretends to be the destination node by sending an ARP response to the originating node that associates the router’s MAC address with the destination node’s IP address (acts as a proxy for the destination node). The router then takes responsibility for routing traffic to the real destination.

For more information on proxy ARP, refer to the 7705 SAR Router Configuration Guide, “Proxy ARP”.

6.2.6. Configurable ARP Retry Timer

A timer is available to configure a shorter retry interval when an ARP request fails. An ARP request may fail for a number of reasons, such as network connectivity issues. By default, the 7705 SAR waits 5000 ms before retrying an ARP request. The configurable retry timer makes it possible to shorten the retry interval to between 100 and 30 000 ms.

Note:

The ARP retry default value of 5000 ms is intended to protect CPU cycles on the 7705 SAR, especially when it has a large number of interfaces. Configuring the ARP retry timer to a value shorter than the default should be done only on mission-critical links, such as uplinks or aggregate spoke SDPs transporting mobile traffic; otherwise, the retry interval should be left at the default value.

The configurable ARP retry timer is supported on VPRN and IES service interfaces, as well on the router interface.

6.2.7. Unnumbered Interfaces

Unnumbered interfaces are supported on IES and VPRN services for IPv4. Unnumbered interfaces are point-to-point interfaces that are not explicitly configured with a dedicated IP address and subnet; instead, they borrow (or link to) an IP address from another interface on the system (the system IP address, another loopback interface, or any other numbered interface) and use it as the source IP address for packets originating from the interface.

This feature is supported via both dynamic and static ARP for unnumbered interfaces to allow interworking with unnumbered interfaces that may not support dynamic ARP.

The use of unnumbered interfaces has no effect on IPv6 routes; however, the unnumbered command must only be used in cases where IPv4 is active (IPv4 only and mixed IPv4/IPv6 environments). When using an unnumbered interface for IPv4, the loopback address used for the unnumbered interface must have an IPv4 address. The interface type for the unnumbered interface is automatically point-to-point.

6.2.8. Troubleshooting and Fault Detection Services

Bidirectional forwarding detection (BFD) can be configured on the IES interface. BFD is a simple protocol for detecting failures in a network. BFD uses a “hello” mechanism that sends control messages periodically to the far end and expects to receive periodic control messages from the far end. On the 7705 SAR, BFD is implemented for IGP and BGP protocols, including static routes, in asynchronous mode only, meaning that neither end responds to control messages; rather, the messages are sent periodically from each end.

To support redundancy with fast switchover, BFD must be enabled to trigger the handoff to the other route in case of failure.

Due to the lightweight nature of BFD, it can detect failures faster than other detection protocols, making it ideal for use in applications such as mobile transport.

If BFD packets are not received in the configured amount of time, the associated route is declared “not active”, causing a reroute to an alternative path, if any.

Note:

Link failures detected by BFD will disable the IP interface.

The 7705 SAR also supports Internet Control Message Protocol (ICMP and ICMPv6). ICMP is a message control and error reporting protocol that also provides information relevant to IP packet processing. For more information on ICMP and ICMPv6, refer to the 7705 SAR Router Configuration Guide, “ICMP and ICMPv6”.

6.2.9. VRRP on IES Interfaces

VRRP can be implemented on IES service interfaces to participate as part of a virtual router instance. This implementation prevents a single point of failure by ensuring access to the gateway address, which is configured on all IES service interfaces in the VRRP. VRRPv3 can also be implemented on IES service interfaces, including r-VPLS interfaces for IES.

The 7705 SAR supports VRRPv3 for IPv4 and IPv6 as described in RFC 5798. Within a VRRP router, the virtual routers in each of the IPv4 and IPv6 address families are in separate domains and do not overlap.

Note:

  1. VRRPv3 for IPv6 is not support on a Layer 3 spoke SDP termination.
  2. VRRP is not supported on an IPSec public interface.

For information on VRRP and VRRP IES service interface parameters, as well as the configuration parameters of VRRP policies, refer to the “VRRP” section in the 7705 SAR Router Configuration Guide. CLI command descriptions for VRRP policies are also given in the 7705 SAR Router Configuration Guide.

For CLI command descriptions related to IES service interfaces, see IES Command Reference.

6.2.10. SAPs

6.2.10.1. Encapsulations

The following SAP encapsulations are supported on the 7705 SAR Internet Enhanced Service:

  1. Ethernet null
  2. Ethernet dot1q
  3. Ethernet qinq
  4. PPP/MLPPP/MC-MLPPP

6.2.10.2. Routing Protocols

The OSPFv2 routing protocol is supported on IES SAPs (that is, access IP interfaces).

The SAP for the IES IP interface is created at the IES service level, but the routing protocol for the IES IP interface is configured at the routing protocol level for the main router instance in the global context. Refer to the chapter on OSPF in the 7705 SAR Routing Protocols Guide for information on configuring the OSPF routing protocol.

6.2.10.3. QoS Policies

When applied to an Internet Enhanced Service SAP, service ingress QoS policies only create the unicast queues defined in the policy.

Service egress QoS policies function in the same way as Ethernet and IP pseudowire services, where class-based queues are created based on the QoS policy. Multiple queues are supported. Refer to the 7705 SAR Quality of Service Guide, “Creating a Service Egress QoS Policy”.

Both Layer 2 and Layer 3 match criteria can be used in the QoS policies for traffic classification in an IES.

6.2.10.4. QinQ (IES)

IES supports QinQ functionality. For details, see QinQ Support.

6.2.10.5. IP Filter Policies on an IES SAP

IPv4 filter policies can be applied to ingress IES management SAPs.

IPv4 and IPv6 filter policies can be applied to both ingress and egress IES SAPs (null, dot1q, or qinq interfaces).

Configuration and assignment of IP filter policies is similar for all services. Refer to the 7705 SAR Router Configuration Guide, “Filter Policies”, for information on configuring IP filters.

6.2.11. Spoke SDP Termination to IES

This feature enables a customer to exchange traffic between a VLL or VPLS (Layer 2) service and an IES or VPRN (Layer 3) service. Customer premises traffic coming in from a VLL or VPLS service (SAP to spoke SDP) is forwarded over the IP/MPLS network to the IES or VPRN service, and vice versa. Network QoS policies can be applied to the spoke SDP to control traffic forwarding to the Layer 3 service.

In a Layer 3 spoke SDP termination to an IES or VPRN service, where the destination IP address resides within the IES or VPRN network, CE device-generated ARP frames must be processed by the Layer 3 interface. When an ARP frame is received over the spoke SDP at the Layer 3 interface endpoint, the 7705 SAR responds to the ARP frame with its own MAC address. When an ARP request is received from the routed network and the ARP entry for the CE device that is connected to the spoke SDP is not known, the 7705 SAR initiates an ARP frame to resolve the MAC address of the next hop or CE device.

Figure 97 shows traffic terminating on a specific IES or VPRN service that is identified by the SDP ID and VC label present in the service packet.

Figure 97:  SDP ID and VC Label Service Identifiers (Conceptual View of the Service) 

Figure 98 shows a spoke SDP terminating directly into an IES. In this case, a spoke SDP could be tied to an Epipe or a hierarchical VPLS service. There is no configuration required on the PE connected to the CE.

Figure 98:  IES Spoke SDP Termination 

Ethernet spoke SDP termination for IES is supported over the following network uplinks:

  1. Ethernet network ports (null or dot1q encapsulation)
  2. PPP/MLPPP network ports. For information on PPP/MLPPP ports, refer to the 7705 SAR Interface Configuration Guide, “Access, Network, and Hybrid Ports”
  3. GPON module ports and DSL module ports when the module is installed in the 7705 SAR-M (variants with module slots)
  4. POS ports

Spoke SDP termination for IES supports the following:

  1. Ethernet PW to VRF
  2. interface shutdown based on PW standby signaling
  3. spoke SDP ingress IP filtering with filter logging
  4. label withdrawal for spoke SDPs terminated on IES
  5. statistics collection
  6. VCCV ping (type 2)

A spoke SDP on an IES interface can be connected to the following entities:

  1. Epipe spoke SDP
  2. Epipe spoke SDP redundancy with standby-signal-master enabled
  3. IES interface
  4. VPRN interface
  5. VPLS spoke SDP
  6. VPLS spoke SDP redundancy with suppress-standby-signaling disabled

Figure 99 shows an example of backhauling from a given site that uses PW and IES on the 7705 SAR. An individual PW is configured on a per-CE device or a per-service basis. For routing services, this PW can be terminated to an IES at the 7750 SR end. This scenario offers per-service OAM and redundancy capabilities. Because there is no local communication on the remote 7705 SAR, traffic between any two devices connected to the 7705 SAR must traverse through the 7750 SR at the MTSO/CO.

Figure 99:  Pseudowire-Based Backhaul (Spoke SDP Termination at 7750 SR) 

6.2.12. Bandwidth Optimization for Low-speed Links

The 7705 SAR can be used in deployments where the uplink bandwidth capacity and requirements are considerably less than if the router is used for fixed or mobile backhaul applications. For example, the 7705 SAR can be used to direct traffic from multiple individual homes for applications such as smart meter aggregation or relay connectivity. Connecting to end systems such as smart meters or relays requires uplink bandwidth capacity in terms of hundreds of kilobits per second, rather than hundreds of megabits per second.

One way to optimize operation in lower-bandwidth applications is to minimize head-of-line (HoL) blocking caused by large packets. HoL blocking occurs when transmission of a large non-mission-critical packet delays a mission-critical packet beyond acceptable limits. The propagation delay of large packets over a slow link is fairly significant. For example, the propagation delay when transmitting a 1500-byte packet over a 100 kb/s link is 120 ms. If a mission-critical packet is queued immediately after the first bit of a non-mission-critical 1500-byte packet begins transmission, the mission-critical packet must wait 120 ms before the uplink is available again.

To minimize HoL blocking, the 7705 SAR now supports a lower MTU of 128 bytes (from the original 512-byte minimum) so that large IP packets can be fragmented into 128-byte chunks. In the preceding example, transmitting a 128-byte packet over a 100 kb/s link will only delay the next packet by 10.24 ms.

This lower MTU is supported on IES and VPRN interfaces (access interfaces) and on network interfaces. The IP MTU is derived from the port MTU, unless specifically configured with the ip-mtu command. This command is supported on access interfaces only.

The following must be considered when using a lower IP MTU:

  1. applicability – the lower IP MTU is only applicable for IP forwarded traffic and cannot be applied to pseudowire or VPLS traffic
  2. reassembly – the far-end/destination node must reassemble the packet before it can process the data, which may impact the performance of the end system and/or may require different hardware to perform the reassembly
  3. extra overhead – each fragment must have an IPv4 header so that all fragments of the packet can be forwarded to the destination. Care must be taken to ensure that the extra IP overhead for each fragment does not offset the gain achieved by using the lower MTU. As an example, for a 128-byte packet, the IPv4 header, which is 20 bytes in length, constitutes approximately 15% of the total packet size.
Note:

  1. Lower IP MTU applies to IPv4 applications only. As per RFC 2640, IPv6 interfaces or dual-stack interfaces should not be configured to a value lower than 1280 bytes.
  2. Lower IP MTU is supported only on Ethernet encapsulated ports.
  3. Most routing and signaling protocols, such as OSPF, IS-IS, and RSVP-TE, cannot be supported with port MTUs lower than 512 bytes due to the protocol layer requirements and restrictions.
  4. Special care must be taken with routing protocols that use TCP, such as BGP and LDP. The minimum TCP MSS value supported on the 7705 SAR is 384 bytes; therefore, these protocols should only be enabled on links that can transport 384-byte IP packets without fragmentation. If there is a mismatch in TCP MSS in the network, this mismatch can potentially cause severe network performance issues due to the overhead caused by fragmentation and retransmissions, it can cause multi-vendor interoperability issues, and it can potentially cause the protocols to continuously flap.
  5. Not all OAM diagnostics are supported with lower port MTUs. Detailed information is provided in OAM Diagnostics Restrictions with Lower IP MTU.

6.2.12.1. OAM Diagnostics Restrictions with Lower IP MTU

OAM tests require a minimum network port MTU in order to run; this value depends on the test. If the port MTU is set to a value lower than the minimum requirement, the test will fail.

If the port MTU is set to a value that meets the minimum requirement, the packet size parameter can be configured for the test (for example, oam sdp-ping 1 size 102).

If the size parameter is not specified, the system builds the packet based on the default payload size. If the size parameter is configured and is greater than the default payload size, padding bytes are added to equal the configured value.

The packet size is dependent on the port MTU value; that is, if the minimum port MTU value is used, there are restrictions on the packet size. If the configured size is greater than the maximum value supported with the minimum port MTU, the test will fail.

Table 92 and Table 93 list the minimum port MTU required for each OAM test and the maximum size of the OAM packet that can be configured when the minimum port MTU is used, based on SDP tunnel type.

Note:

RSVP LSPs will not come up if the network port MTU value is lower than 302 bytes.

Table 92:  Port MTU Requirements for OAM Diagnostics (GRE Tunnels) 

SDP Type: GRE

Test Type

Minimum Network Port MTU Requirement over Ethernet Dot1q Encapsulation (Bytes)

OAM Test Size Range (Bytes)

sdp-ping

128

72 to 82

svc-ping

196

N/A 1

vccv-ping

143

1 to 93

vccv-trace

143

1 to 93

vprn-ping

182

1 to 136

vprn-trace

302

1 to 256

mac-ping

188

1 to 142

mac-trace

240

1 to 194

cpe-ping

186

N/A 1

    Note:

  1. Size is not configurable
Table 93:  Port MTU Requirements for OAM Diagnostics (LDP Tunnels) 

SDP Type: LDP

Test Type

Minimum Network Port MTU Requirement over Ethernet Dot1q Encapsulation (Bytes)

OAM Test Size Range (Bytes)

lsp-ping

128

1 to 106

lsp-trace

128

1 to 104

sdp-ping

128

72 to 102

svc-ping

176

N/A 1

vccv-ping

128

1 to 98

vccv-trace

128

1 to 98

vprn-ping

182

1 to 156

vprn-trace

302

1 to 276

mac-ping

168

1 to 142

mac-trace

220

1 to 194

cpe-ping

166

N/A 1

    Note:

  1. Size is not configurable

For information on OAM diagnostics, refer to the 7705 SAR OAM and Diagnostics Guide.