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.
Topics in this chapter include:
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 section include:
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:
IES management service is also supported on the T1/E1 ports on the following:
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.
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.
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.
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:
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. |
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. |
IP ECMP allows the configuration of load balancing across all IP interfaces at the system level or interface level on the network side. You can include Layer 4 port attributes and/or the TEID attribute in the hashing algorithm with the l4-load-balancing and teid-load-balancing commands in the config>service>ies> interface context. Configuration at the interface level overrides the system-level settings for the specific interface.
For more information on IP ECMP, refer to the7705 SAR Router Configuration Guide, “Static Routes, Dynamic Routes, and ECMP”.
Topics in this section include:
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 91. 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.
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:
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:
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:
|
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:
|
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.
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:
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.
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.
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.
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.
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:
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.
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 | ✓ | ✓ |
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”.
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.
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.
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”.
The following SAP encapsulations are supported on the 7705 SAR Internet Enhanced Service:
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.
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.
IES supports QinQ functionality. For details, see QinQ Support.
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.
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 92 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 93 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.
Ethernet spoke SDP termination for IES is supported over the following network uplinks:
Spoke SDP termination for IES supports the following:
A spoke SDP on an IES interface can be connected to the following entities:
Figure 94 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.
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:
Note:
|
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. |
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:
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:
For information on OAM diagnostics, refer to the 7705 SAR OAM and Diagnostics Guide.