IES-708-22A FCS SUPPORT NOTE V01 071022 - Zyxel · IES-708-22A 8-port G..bis mini-DSLAM Support Notes Version 3.52 October 2007

IES-708-22A 8-port G..bis mini-DSLAM

Support Notes Version 3.52 October 2007

IES-708-22A Support Notes

All contents copyright (c) 2004 ZyXEL Communications Corporation. 2

INDEX Application Notes ............................................................................................................................ 4

Layer-2 Switching/ Bridging ....................................................................................... 4 1. Introduction................................................................................................................... 4 2. Switching Example ....................................................................................................... 5 3. Broadcast and Multicast................................................................................................ 6

VLAN Overview.......................................................................................................... 8 1. Tag-based VLAN Overview ......................................................................................... 8 2. How does 802.1Q VLAN work ? ................................................................................. 9 2.3 Egress Process :......................................................................................................... 12

IGMP Snooping........................................................................................................ 13 1. IGMP Overview.......................................................................................................... 13 2. What is IGMP Snooping ............................................................................................. 16

Multiple PVC ............................................................................................................ 18 1. ATM Brief Introduction .............................................................................................. 18 2. The VPI and VCI ........................................................................................................ 18 3. Multiple PVCs ............................................................................................................ 19 4. The implementation of ZyXEL IP DSLAM ............................................................... 19

DHCP Relay Agent Information Option 82 ............................................................... 23 1. General Description .................................................................................................... 23 2. DHCP Packet Flow ..................................................................................................... 24 3. Internal packet flow .................................................................................................... 25 4. "Relay Agent Information" option packet format ....................................................... 26

Network Management Using SNMP ........................................................................ 28 1. SNMP Overview......................................................................................................... 28 2. SNMP Operations ....................................................................................................... 32 3. Comparative overview between different versions of SNMP .................................... 36

An example of IES-708-22A configuration ............................................................... 39 1. Bonding Overview...................................................................................................... 39 2. Configure the IES-708-22A in STU-R mode.............................................................. 40 3. Configure the IES-708-22A in STU-C mode ............................................................. 53

FAQ ................................................................................................................................................ 66 What is the IES-708-22A? ....................................................................................... 66 What kind of the G.SHDSL standard does IES-708-22A comply?............................ 66 What is the G.SHDSL chipset of IES-708-22A? ....................................................... 66 How many VLAN ID and Static VLAN entry does IES-708-22A supports? .............. 66



What kind of the G.SHDSL.bis functionalities does IES-708-22A support?.............. 66 What kind of the ATM layer functionalities does IES-708-22A support?................... 67 What kind of the Ethernet functionalities does IES-708-22A support? ..................... 67 What kind of the multicasting functionalities does IES-708-22A support?................ 68 What is the default console rate of IES-708-22A? ................................................... 68 What does it mean if the ALM LED lights on?.......................................................... 68 How to upgrade the firmware of IES-708-22A? ....................................................... 68 What is the configuration limitation of IES-708-22A? ............................................... 68



Application Notes

Layer-2 Switching/ Bridging 1. Introduction IES-708-22A operates at Layer 2 of the OSI model. It supports IEEE 802.1d transparent bridging and operate as an Ethernet switch. According to the MAC address, IES-708-22A bridging/switching Ethernet frames between DSL ports and Ethernet ports. Layer 2 switching increases the available bandwidth of a network by creating dedicated network segments and interconnecting the segment. Each segment is a collision domain which can comprise one or more stations/ nodes. Its function is similar to those provided by Ethernet bridge as below: 1.1 MAC Address Learning: A Layer 2 switch automatically learns the MAC addresses of devices attached to each of its port. The MAC addresses to port mappings are stored in Filtering Database (MAC table). 1.2 Aging timer: If the entry in Filtering Database (MAC table) is not flushed by a new frame transmitted the switch within a time limit (Bridge Age Timer, 300 seconds by default), the entry is cleared. 1.3 Forwarding and Filtering Decision : When a Layer 2 switch receives a frame, it identify the destination MAC address of this frame and consult the Filtering Database (MAC table) to determine which port can reach the station. If the address is found, the frame is transmitted only on that port. If not found, the frame is flooded (broadcast) to all ports. The flow chart of Forwarding and Filtering Decision is shown in the following figure.

Figure 1: Forwarding and Filtering flow chart



1.4 Broadcast and Multicast constitute a special case. 2. Switching Example

2.1 Filtering Database is empty, Station A sends a frame to Station B - When a switch is first initialized, the Filtering Database is empty. - Station A with MAC address 00:A0:C5:11:11:11 sends traffic to Station B with

MAC address 00:A0:C5:22:22:22. - The switch receives the frame and stores it in temporary buffer. - The switch notes the source MAC address and associates it with port 1. The

source MAC address 00:A0:C5:11:11:11 is added to the Filtering Database. A MAC entry is cached. If the entry is not flushed by a new frame transmitted the switch within a time limit (Bridge Age Timer, 300 seconds by default ), the entry is cleared.

- Since the switch doesn't know what port connects it to the destination station, this frame is forwarding to all connected ports, this is called flooding. Flooding is the least efficient way to transmit data across a switch because it wastes bandwidth.

MAC entry of Forwarding Database is shown as below: Port MAC Address Age 1 00:A0:c5:11:11:11 10

Station A sends a frame to Station B



2.2 Complete Filtering Database is built, Station B send a frame to Station C - As long as all stations send out data frames, the switch will learn the MAC

addresses and build the complete Filtering Database. - Station B with MAC address 00:A0:C5:22:22:22 sends traffic to Station C with

MAC address 00:A0:C5:33:33:33. - The switch receives the frame and store it in temporary buffer. - The destination MAC address 00:A0:C5:33:33:33 of the transmitted frame is

existing in Filtering Database. The switch determine to forward the frame to only port 3.

- The switch doesn't transmit the frame on port 1 and port 4 in order to save the bandwidth on these links. This action is known as frame filtering.

MAC entries of Forwarding Database are shown as below :

Port MAC Address Age 1 00:A0:C5:11:11:11 120

2 00:A0:C5:22:22:22 50

3 00:A0:C5:33:33:33 80

4 00:A0:C5:44:44:44 10

Station B sends a frame to Station C

3. Broadcast and Multicast Broadcast and Multicast frames constitute a special case. Since Broadcast and Multicast frames may be sent to all stations, the switch normally floods theses frames to all ports other than the originating port. IGMP Multicast frame is transmitted with associated GDA (Group Destination Address) MAC address 01:00:5E:xx:xx:xx.



Broadcast frame is transmitted with destination MAC address FF:FF:FF:FF:FF:FF. A switch never learns a Broadcast and Multicast address because Broadcast and Multicast address never appears as the source MAC address of frame.

MAC entries of Forwarding Database are shown as below :

Port MAC Address Age 1 00:A0:C5:11:11:11 120

2 00:A0:C5:22:22:22 50

3 00:A0:C5:33:33:33 80

4 00:A0:C5:44:44:44 10

Station A sends a Broadcast/ Multicast frame to Station C

An exception, if the switch supports IGMP Snooping, the Multicast frames will not be flooding. These Multicast frames are forwarding to proper destination port only. For more detail, please refer to IGMP Snooping Application Notes.



VLAN Overview

A VLAN (Virtual Local Area Network) allows a physical network to be partitioned into multiple logical networks. Stations on a logical network belong to one group called VLAN Group. A station can belong to more than one group. The stations on the same VLAN group can communicate with each other. With VLAN, a station cannot directly talk to or hear from stations that are not in the same VLAN group(s); the traffic must first go through a router.

In MTU or IP-DSLAM applications, VLAN is vital in providing isolation and security among the subscribers. When properly configured, VLAN prevents one subscriber from accessing the network resources of another on the same LAN, thus a user will not see the printers and hard disks of another user in the same building.

VLAN also increases network performance by limiting broadcasts to a smaller and more manageable logical broadcast domain. A VLAN group is a broadcast domain. In traditional Layer-2 switched environments, all broadcast packets go to each and every individual port. With VLAN, all broadcasts are confined to a specific broadcast domain.

There are two most popular VLAN implementation, Port-based VLAN and IEEE 802.1q Tagged VLAN. IES-2000/3000 Series supports both VLAN implementation. The most difference between both VLAN implementation is Tagged VLAN can across Layer-2 switch but Port-based VLAN can not. The port-based VLAN in IES is used for port-isolation purpose only.

IEEE 802.1Q Tag-based VLAN 1. Tag-based VLAN Overview Regarding IEEE 802.1Q standard, Tag-based VLAN uses an extra tag in the MAC header to identify the VLAN membership of a frame across bridges. This tag is used for VLAN and QoS (Quality of Service) priority identification. The VLANs can be created statically by hand or dynamically through GVRP. The VLAN ID associates a frame with a specific VLAN and provides the information that switches need to process the frame across the network. A tagged frame is four bytes longer than an untagged frame and contains two bytes of TPID (Tag Protocol Identifier, residing within the type/length field of the Ethernet frame) and two bytes of TCI (Tag Control Information, starts after the source address field of the Ethernet frame).



• TPID : TPID has a defined value of 8100 in hex. When a frame has the EtherType equal to 8100, this frame carries the tag IEEE 802.1Q / 802.1P.

• Priority : The first three bits of the TCI define user priority, giving eight (2^3) priority levels. IEEE 802.1P defines the operation for these 3 user priority bits.

• CFI : Canonical Format Indicator is a single-bit flag, always set to zero for Ethernet switches. CFI is used for compatibility reason between Ethernet type network and Token Ring type network. If a frame received at an Ethernet port has a CFI set to 1, then that frame should not be forwarded as it is to an untagged port.

• VID : VLAN ID is the identification of the VLAN, which is basically used by the standard 802.1Q. It has 12 bits and allow the identification of 4096 (2^12) VLANs. Of the 4096 possible VIDs, a VID of 0 is used to identify priority frames and value 4095 (FFF) is reserved, so the maximum possible VLAN configurations are 4,094.

Note that user priority and VLAN ID are independent of each other. A frame with VID (VLAN Identifier) of null (0) is called a priority frame, meaning that only the priority level is significant and the default VID of the ingress port is given as the VID of the frame.

2. How does 802.1Q VLAN work ?

According to the VID information in the tag, the switch forward and filter the frames among ports . These ports with same VID can communicate with each other. IEEE 802.1Q VLAN function contains the following three tasks, Ingress Process,



Forwarding Process and Egress Process.

2.1 Ingress Process :

Each port is capable of passing tagged or untagged frames. Ingress Process identifies if the incoming frames contain tag, and classifies the incoming frames belonging to a VLAN. Each port has its own Ingress rule. If Ingress rule accept tagged frames only, the switch port will drop all incoming non-tagged frames. If Ingress rule accept all frame type, the switch port simultaneously allow the incoming tagged and untagged frames :

• When a tagged frame is received on a port, it carries a tag header that has a explicit VID. Ingress Process directly pass the tagged frame to Forwarding Process.

• An untagged frame doesn't carry any VID to which it belongs. When a untagged frame is received, Ingress Process insert a tag contained the PVID into the untagged frame. Each physical port has a default VID called PVID (Port VID). PVID is assigned to untagged frames or priority tagged frames (frames with null (0) VID) received on this port.



After Ingress Process, all frames have 4-bytes tag and VID information, and then go to Forwarding Process.

2.2 Forwarding Process : The Forwarding Process decide to forward the received frames according to the the Filtering Database. If you want to allow the tagged frames can be forwarded to certain port, this port must be the egress port of this VID. The egress port is an outgoing port for the specified VLAN, that is, frames with specified VID tag can go through this port. The Filtering Database stores and organizes VLAN registration information useful for switching frames to and from switch ports. It consists of static registration entries (Static VLAN or SVLAN table) and dynamic registration entries (Dynamic VLAN or DVLAN table). SVLAN table is manually added and maintained by the administrator. DVLAN table is automatically learned via GVRP protocol, and can't be created and upgraded by the administrator. The VLAN entries in Filtering Database has the following information :

a. VID : VLAN ID b. Port : The switch port number c. Ad Control : Registration administration control. There are 3 type of ad

control, including forbidden registration, fixed registration and normal registration.

• Forbidden registration : This port is forbidden to be the egress port of specified VID..

• Fixed registration : While ad control is fixed registration, it means this is a static registration entry. This port is the egress port of the specified VID (a member port of the specified VLAN). The frames with specified VID tag can go through this port.

• Normal registration : While ad control is normal registration, it means



this is a dynamic registration entry. The forwarding decision is depended on Dynamic VLAN table.

d. Egress tag Control : This information is used for Egress Process. The value may be tagged or untagged. If the value is tagged, the outgoing frame on the egress port is tagged. If the value is untagged, the tag will be removed before frame leaves the egress port.

VID Port Ad Control Tag Control 10 1 Forbidden Tag

10 2 Fixed Tag

10 3 Normal Untag

20 1 Fixed Tag

20 5 Fixed Untag

Filtering Datebase

VID Egress Port 10 1

10 2

20 3

Dynamic VLAN (DVLAN) table 2.3 Egress Process : The Egress Process decide if the outgoing frames but be sent tagged or untagged. Egress Process refer to the egress tag control information in Filtering Database. If the value is tagged, the outgoing frame on the egress port is tagged. If the value is untagged, the tag will be removed before frame leaves the egress port.



IGMP Snooping 1. IGMP Overview

Traditionally, IP packets are transmitted in one of either two ways - Unicast (1 sender to 1 recipient) or Broadcast (1 sender to everybody on the network). Multicast delivers IP packets to just a group of hosts on the network. IGMP (Internet Group Multicast Protocol) is a session-layer (layer-3) protocol used to establish membership in a Multicast group. It can register a router to receive specific multicast traffic. Refer to RFC 1112 and RFC 2236 for information on IGMP versions 1 and 2 respectively.

1.1 Multicast Address

Multicast IP address are Class D IP address, from 224.0.0.0 to 239.255.255.255. They are also referred to as Group Destination Address (GDA). For each GDA, there is an associated MAC address. This GDA MAC address is formed by 01:00:5E:XX:XX:XX, followed by the latest 23 bits of the GDA multicast IP address in hex.

For Example :

• GDA 224.10.10.10 corresponds to MAC address 01:00:5E:0A:0A:0A • GDA 239.255.255.255 corresponds to MAC address 01:00:5E:FF:FF:FF

1.2 IGMP version 1 (RFC-1112)

IGMP version 1 messages are transmitted with the following fields.

• Version : should be 1 • Type : there are 2 types of IGMP messages.1 = Host Membership Query, 2 =

Host Membership Report.



• GDA : Group Destination Address

Membership Report is issued by host that want to join a specific multicast group (GDA). When IGMP router receive the Membership Report, it will add the GDA to the multicast routing table and start forwarding the IGMP traffic to this group. Membership Queries are issued by router at regular intervals to check whether there is still a host interested in the GDA in that segment. Host Membership Reports are sent either when the host wants to receive GDA traffic or response for a membership query from IGMP router.

IGMP version 1 doesn't have leave mechanism. When a host does not want to receive the IGMP traffic any more, it just quits silently. IGMP multicast routers periodically send Host Membership Query messages (hereinafter called Queries) to discover which host groups have members on their attached local networks. If no Reports are received for a particular group after some number of Queries, the routers assume that that group has no local members and that they need not forward remotely-originated multicasts for that group onto the local network.

The Host Membership Report messages are transmitted with the following datagram :

Layer 2 information :

• Source MAC address : MAC address of the host • Destination MAC MAC address : MAC address for the GDA

(01:00:5E:XX:XX:XX)

Layer 3 information :

• Source IP address : IP address of the host • Destination IP address : GDA (from 224.0.0.0 to 239.255.255.255)

1.3 IGMP version 2 (RFC-2236)

IGMP version 2 messages are transmitted with the following fields. The version field is removed



• Type : there are 3 types of IGMP messages. 0x11 = Membership Query, 0x16 = Version 2 Membership Report, 0x17 = Leave Group. There is an additional type of message, for backwards-compatibility with IGMPv1. 0x12 = Version 1 Membership Report.

• MRT : Maximal Response Time, this field is meaningful only in Membership Query messages, and specifies the maximum allowed time before sending a responding report in units of 1/10 second. In all other messages, it is set to zero by the sender and ignored by receivers.

• GDA : Group Destination Address

Leave Group message is a new type different from IGMP version 1. Membership Report is issued by host that want to join a specific multicast group (GDA). When IGMP router receive the Membership Report, it will add the GDA to the multicast routing table and start forwarding the IGMP traffic to this group. Membership Queries are issued by router at regular intervals to check whether there is still a host interested in the GDA in that segment. Host Membership Reports are sent either when the host wants to receive GDA traffic or response for a membership query from IGMP router.

If a host does not want to receive the IGMP traffic any more, it send a Leave Group message. When the multicast router receives this Leave Group message, it remove the GDA from the multicast routing table. In addition, IGMP multicast routers periodically send Host Membership Query messages (hereinafter called Queries) to discover which host groups have members on their attached local networks. If no Reports are received for a particular group after some number of Queries, the routers assume that that group has no local members and that they need not forward remotely-originated multicasts for that group onto the local network. In addition, IGMP version 2 have leave mechanism.

The Layer 2 and Layer 3 information of Host Membership Report messages are same with IGMP version 1.



2. What is IGMP Snooping

A layer-2 switch supported IGMP snooping can passively snoop on IGMP Query, Report and Leave (IGMP version 2) packets transferred between IP Multicast Routers/Switches and IP Multicast hosts to learn the IP Multicast group membership. It checks IGMP packets passing through it, picks out the group registration information, and configures multicasting accordingly.

Without IGMP snooping, multicast traffic is treated in the same manner as broadcast traffic, that is , it is forwarded to all ports. With IGMP snooping, multicast traffic of a group is only forwarded to ports that have members of that group. IGMP Snooping generates no additional network traffic, allowing you to significantly reduce multicast traffic passing through your switch.

2.1 Switch without IGMP Snooping

By default, a Ethernet switch floods multicast traffic within the broadcast domain, and this can consume a lot of bandwidth if many multicast servers are sending streams to the segment. Multicast traffic is flooded because a switch usually learns MAC addresses by looking into the source address field of all the frames it receives. But, since a multicast GDA MAC address (01:00:5E:XX:XX:XX) is never used as source MAC address for a packet and since they do not appear in the MAC Filtering Database, the switch has no method for learning them.

2.2 Join a Multicast Group

When a host want to join a multicast group, it sends a IGMP Report message specified the GDA it wants to join. The IGMP snooping switch will recognize the IGMP Report message and add a GDA MAC address of associated port in the MAC Filtering Database. While multicast traffic is transmitted to the switch next time, it will directly forward the traffic to the ports associated with this GDA MAC address regarding the Filtering Database.

2.3 Leave a Multicast Group

For IGMP version 2, if a host does not want to receive the IGMP traffic any more, it send a Leave Group message. As long as the IGMP snooping switch receives this Leave Group message, it sends a IGMP group specified query message to determine if any device behind that port is interested in the specific multicast group traffic. If the



switch doesn't receive any IGMP Report message, it remove the GDA MAC address from the associated port in the MAC Filtering Database.

For IGMP version 1, if a host does not want to receive the IGMP traffic, it just silently quit the group. IGMP multicast routers periodically send Host Membership Query messages to discover if any member is still interesting in the specific multicast group traffic. As long as the IGMP snooping switch receives this Query Group message, it forward the message to the associated port including in the multicast group. If the switch doesn't receive Report Group message for 3 times, it delete the GDA MAC of associated port in the MAC Filtering Database.



Multiple PVC

1. ATM Brief Introduction

ADSL and G.SHDSL technologies are based on the ATM. To know about ADSL and G.SHDSL more, you need to know more about ATM technology.

The purpose of ATM is to provide a high-speed, low-delay multiplexing and switching network to support any type of user traffic, such as voice, data, or video applications.

ATM segments and multiplexes user traffic into small, fixed-length units called cells. The cell is 53 octets, with 5 octets reserved for the cell header. Each cell is identified with virtual circuit identifiers contained in the cell header. An ATM network uses there identifiers to relay the traffic through high-speed switches from the sending customer premises equipment (CPE) to the receiving CPE.

ATM provides no error detection operations on the user payload inside the cell. Ti provides no retransmisson services, and few operations are performed on the small header. The intention of this approach - small cells with minimal services performed - is to implement a network fast enough to support multi-megabit transfer rates.

2. The VPI and VCI

The ITU-T Recommendation requires that an ATM connection be identified with connection identifiers that are assigned for each user connection in the ATM network. The connection is identified by two values in the cell header : the virtual path identifier (VPI) and the virtual channel identifier (VCI). The VPI and VCI fields constitute a virtual circuit identifier. Users are assigned these values when the user enters into a session with a network as a connection-on-demand (SVC - Switched Virtual Circuits), or when a user is provisioned to the network as a PVC (Permanent Virtual Circuits).



3. Multiple PVCs

The DSL technology uses PVCs. In the beginning, each DSL CPE only has one PVC between DSLAM and the CPE for all applications. But it has some limitation in current market because more and more Internet applications are developed today, such as video and voice. These applications request more stable bandwidth and real time services, so the DSLAM and CPE must have QoS feature to protect such kind applications.

One of the solution is to use ATM QoS feature but user still can't differentiate many services via one PVC. If all traffic exists in one PVC, it is hard to guarantee the quality for different services. So user needs the multiple PVC for different services. What is the multiple PVC? From the ATM implement, one physical link can support many PVCs inside. So user can have different PVCs for different applications in one DSL link. Each PVC also can be recognized to be a virtual link so different applications will not be affected by other applications.

4. The implementation of ZyXEL IP DSLAM

ZyXEL implementation of Multiple PVC is to map different PVCs to different 802.1Q VLAN IDs for different services. Since IES is an IP DSLAM, so the ATM is not available anymore inside the IES. The ATM will be terminated on the DSL ports. To provide different services for different PVCs, so IES maps different PVCs to different 802.1Q VLAN IDs for IP environment.

4.1 Super Channel



In the implementation of ZyXEL IES, each PVC only can map to one VLAN. But sometimes you will need more VLANs in one PVC or you just need one PVC for all applications. So there is a "super channel" option in the PVC setting.

What does super channel mean? IES only allow one PVID (VLAN) for one PVC. The "super channel" means all VLANs except the VLAN which had been assigned to the another PVCs will go through this PVC.

For example, DSL port has three PVCs and this port joins VLAN 3,4,5,6,7 five VLANs. PVC 1 is PVID 3 and PVC 2 is PVID 4. If PVC 3 is a super channel, it means the traffic of VLAN 5,6,7 will go through PVC3. The traffic of VLAN 3 will go through PVC 1 and the traffic of VLAN 4 will go through PVC 2. If PVC 3 only is PVID 5, then it means the traffic of VLAN 6 and 7 can't go through this DSL port.

4.2 Only one PVC in one DSL port.

This PVC is equal to the DSL port. So just configure the port with one PVID on the Port Setup and join the VLANs on IES. The PVC needs to configure super channel for all VLANs. Only if you just want one VLAN can pass through this port, then you can un-check the super channel and assign the specific PVID and the port priority on the PVC setup.



4.3 More than two PVCs in one DSL port.

If there are more than two PVCs in one DSL port for different services, only one PVC can be super channel. Other PVCs should assign default port VLAN ID (PVID) and default port priority. The traffic will send to corresponding PVC which is based on the PVID. The super channel can pass every VLANs except the VLAN ID had assigned to other PVC as a PVID. When super channel receives untag frame, it will use the default port VLAN ID and default port priority setting in the "Port Setup", not in the Channel Setup.

4.4 The QoS for IP and ATM.

The 802.1p is also supported with 802.1Q VLAN for IP QoS purpose so the QoS can be done on both ATM and IP segments.





DHCP Relay Agent Information Option 82

1. General Description

In some situations, DHCP should not require a server on each subnet. To allow for scale and economy, DHCP must work across routers or through the intervention of DHCP relay agents. A DHCP relay agent is an Internet host or router that passes DHCP messages between DHCP clients and DHCP servers. DHCP is designed to use the same relay agent behavior as specified in the BOOTP protocol specification.

As to the Relay Agent Information option (option 82), it’s an option inserted by the DHCP relay agent when forwarding client-originated DHCP packets to a DHCP server. Servers recognizing the Relay Agent Information option may use the information to implement IP address or other parameter assignment policies. The DHCP Server echoes the option back verbatim to the relay agent in server-to-client replies, and the relay agent strips the option before forwarding the reply to the client.

The "Relay Agent Information" option is organized as a single DHCP option that contains one or more "sub-options" that convey information known by the relay agent. One of these sub-options is a "circuit ID" which provides a trusted identifier for the incoming circuit. Refer to the RFC 3046 for detailed information about the “DHCP Relay Agent Information Option”.



2. DHCP Packet Flow

The following timeline diagram shows the timing relationships in a typical DHCP client-server interaction.

2.1 The client broadcasts a DHCPDISCOVER message on its local physical subnet. The DHCPDISCOVER message may include options that suggest values for the network address and lease duration. DHCP relay agents may pass the message on to DHCP servers not on the same physical subnet.

2.2 Each server may respond with a DHCPOFFER message that includes an available network address in the 'yiaddr' field (and other configuration parameters in DHCP options). The server transmits the DHCPOFFER message to the client, using the BOOTP relay agent if necessary.

2.3 The client receives one or more DHCPOFFER messages from one or more servers. The client chooses one server from which to request configuration parameters, based on the configuration parameters offered in the DHCPOFFER messages. The client broadcasts a DHCPREQUEST message that must include the 'server identifier' option to indicate which server it has selected, and that may include other options specifying desired configuration values. This DHCPREQUEST message is broadcast and relayed through DHCP/BOOTP relay agents.

2.4 The servers receive the DHCPREQUEST broadcast from the client. Those servers not selected by the DHCPREQUEST message use the message as notification that the client has declined that server's offer. The server selected in the DHCPREQUEST message commits the binding for the client to persistent storage and responds with a DHCPACK message containing the configuration parameters for the requesting client.

2.5 The client receives the DHCPACK message with configuration parameters. The client should perform a final check on the parameters (e.g., ARP for allocated network address), and notes the duration of the lease specified in the DHCPACK message. At this point, the client is configured.



3. Internal packet flow

The following diagram shows a internal packet flow within a DHCP relay agent. Usually those DHCP packets originating from a client will be broadcasted on its local physical subnet. “Path A” shows such a flow.

To insert the “option 82” field into a DHCP request packet, we transfer those DHCP request packets to higher level protocols. Also, to keep the packet-related information for later use, the slot id, ingress port number and vlan id are snooped into a database. Those tasks are finished in the bridge module.

After inserting option 82 field into the DHCP request packet in the dhcprelay module, the packet is forwarded to its DHCP server in unicast way. “Path B” shows such a flow.



For those unicast DHCP response packets destined for the relay agent, the option 82 field must be stripped off if existed. Then the DHCP relay agent forwards the packet to the port connecting to the DHCP client.

4. "Relay Agent Information" option packet format Relay Agent Information Option is a "container" option for specific agent-supplied sub-options. The format of the Relay Agent Information option is:

The length N gives the total number of octets in the Agent Information Field. The Agent Information field consists of a sequence of SubOpt/Length/Value tuples for each sub-option, encoded in the following manner:



From the packet format, it is very easy to understand why it is called “DHCP Relay Agent Information Option 82”. It uses number 82 as an option code number in the head of the DHCP Option packet field. Each “option 82” packet carries many sub-option fields with many sub-values. The sub-value is used to provide information to DHCP server.

The initial assignment of DHCP Relay Agent Sub-options includes two sub-option codes, that is, 1 stands for “Agent Circuit ID Sub-option” and 2 for “Agent Remote ID Sub-option”. Agent Circuit ID Sub-option encodes an agent-local identifier of the circuit from which a DHCP client-to-server packet was received. It is intended to be used by agents in relaying DHCP responses back to the proper circuit. Since the Circuit ID is only locally to a particular relay agent, a circuit ID should be qualified with the gateway address value that identifies the relay agent. IP DSLAM uses this Sub-option. "Agent Remote ID Sub-option" usually is used for Cable Modem, Dial up, etc….

In our present design, we put the Slot ID, Port Number, VLAN ID and an optional extra information string into the circuit-id sub-option. The first two 1-byte fields, slot id and port number, specify the slot location in IES series if the device is a line card and the ingress port number which connects the DHCP client. The next 2-byte field stands for the VLAN ID which the DHCP requests packet carries. As to the last one field, which ranges from 0 byte to 24 bytes, is an optional extra information string carrying other information about this relay agent, e.g. the device name or something else.



Network Management Using SNMP

1. SNMP Overview

The Simple Network Management Protocol (SNMP) is an application layer protocol that facilitates the exchange of management information between network devices. It is part of the Transmission Control Protocol/Internet Protocol (TCP/IP) protocol suite. SNMP enables network administrators to manage network performance, find and solve network problems, and plan for network growth.

The different versions of SNMP are the SNMPv1, SNMPv2c and SNMPv3. Let us get to know each version better. The following is a snippet of each version and it is followed by a detailed comparative overview of the versions.

SNMPv1 : This is the first version of the protocol, which is defined in RFCs 1155 and 1157.

SNMPv2c : This is the revised protocol, which includes improvements to SNMPv1 in the areas of protocol packet types, transport mappings, MIB structure elements but using the existing SNMPv1 administration structure ("community based" and hence SNMPv2c). It is defined in RFC 1901, RFC 1905, and RFC 1906.

SNMPv3 : SNMPv3 defines the secure version of the SNMP protocol. SNMPv3 also facilitates remote configuration of the SNMP entities, which make remote administration of SNMP entities a much simpler task. It is defined by RFC 1905, RFC 1906, RFC 2261, RFC 2262, RFC 2263, RFC 2264, and RFC 2265.

SNMPv1 was the standard and the first version of SNMP, which is defined in RFCs 1155 and 1157. The SNMPv2 was created as an update of SNMPv1 adding several features. The key enhancements to SNMPv2 are focused on the SMI, Manager-to-manager capability and protocol operations. The SNMPv2c combines the community-based approach of SNMPv1 with the protocol operation of SNMPv2 and omits all SNMPv2 security features. One notable deficiency in SNMP was the difficulty of monitoring networks, as opposed to nodes on networks. A substantial functional enhancement to SNMP was achieved by the definition of a set of standardized management objects referred to as the Remote Network Monitoring (RMON) MIB. Another major deficiency in SNMP was the complete lack of security facilities. The development of SNMPv3 was based on the security issues. SNMPv3 defines two



security-related capabilities. The User-Based Security Model (USM) and the View-Based Security Model (VACM).

An SNMP-managed network consists of three key components: managed devices, agents, and network-management systems (NMSs).

A managed device is a network node that contains an SNMP agent and that resides on a managed network. Managed devices collect and store management information and make this information available to NMSs using SNMP. Managed devices, sometimes called network elements, can be routers and access servers, switches and bridges, hubs, computer hosts, or printers.

An agent is a network-management software module that resides in a managed device. An agent has local knowledge of management information and translates that information into a form compatible with SNMP.

An NMS executes applications that monitor and control managed devices. NMSs provide the bulk of the processing and memory resources required for network management. One or more NMSs must exist on any managed network.



1.1 SNMP Basic Commands

Managed devices are monitored and controlled using four basic SNMP commands: read, write, trap, and traversal operations.

The read command is used by an NMS to monitor managed devices. The NMS examines different variables that are maintained by managed devices.

The write command is used by an NMS to control managed devices. The NMS changes the values of variables stored within managed devices.

The trap command is used by managed devices to asynchronously report events to the NMS. When certain types of events occur, a managed device sends a trap to the NMS.

Traversal operations are used by the NMS to determine which variables a managed device supports and to sequentially gather information in variable tables, such as a routing table.

1.2 SNMP Management Information Base

A Management Information Base (MIB) is a collection of information that is organized hierarchically. MIBs are accessed using a network-management protocol such as SNMP. They are comprised of managed objects and are identified by object identifiers.

A managed object (sometimes called a MIB object, an object, or a MIB) is one of any number of specific characteristics of a managed device. Managed objects are comprised of one or more object instances, which are essentially variables.

Two types of managed objects exist: scalar and tabular. Scalar objects define a single object instance. Tabular objects define multiple related object instances that are grouped in MIB tables.

An object identifier (or object ID) uniquely identifies a managed object in the MIB hierarchy. The MIB hierarchy can be depicted as a tree with a nameless root, the levels of which are assigned by different organizations. Figure 2 illustrates the MIB tree.



The top-level MIB object IDs belong to different standards organizations, while lower-level object IDs are allocated by associated organizations.

Vendors can define private branches that include managed objects for their own products. MIBs that have not been standardized typically are positioned in the experimental branch.

The managed object reboot can be uniquely identified either by the object name — iso.identified-organization.dod.internet.private.enterprise.zyxel.products.accessSwitch.accessSwitch-traps.reboot — or by the equivalent object descriptor, 1.3.6.1.4.1.890.1.5.0.1

1.3 SNMP and Data Representation

SNMP must account for and adjust to incompatibilities between managed devices. Different computers use different data representation techniques, which can



compromise the capability of SNMP to exchange information between managed devices. SNMP uses a subset of Abstract Syntax Notation One (ASN.1) to accommodate communication between diverse systems.

2. SNMP Operations

2.1 SNMPv1 Operations

SNMP itself is a simple request/response protocol. 4 SNMPv1 operations are defined as below.

• Get Allows the NMS to retrieve an object variable from the agent.

• GetNext Allows the NMS to retrieve the next object variable from a table or list within an agent. In SNMPv1, when a NMS wants to retrieve all elements of a table from an agent, it initiates a Get operation, followed by a series of GetNext operations.

• Set Allows the NMS to set values for object variables within an agent.

• Trap Used by the agent to inform the NMS of some events.

The SNMPv1 messages contains two part. The first part contains a version and a community name. The second part contains the actual SNMP protocol data unit (PDU) specifying the operation to be performed (Get, Set, and so on) and the object values involved in the operation. The following figure shows the SNMPv1 message format.



The SNMP PDU contains the following fields:

• PDU type Specifies the type of PDU. • Request ID Associates requests with responses. • Error status Indicates an error and an error type. • Error index Associates the error with a particular object variable. • Variable-bindings Associates particular object with their value.

2.2 SNMPv2c Operations

The Get, GetNext, and Set operations used in SNMPv1 are exactly the same as those used in SNMPv2c. SNMPv2c, however, adds and enhances protocol operations. The SNMPv2c trap operation, for example, serves the same function as the one used in SNMPv1. However, a different message format is used.

SNMPv2c also defines two new protocol operations:

• GetBulk—Used by the NMS to efficiently retrieve large blocks of data, such as multiple rows in a table. GetBulk fills a response message with as much of the requested data as fits.

• Inform—Allows one NMS to send trap information to another NMS and receive a response. If the agent responding to GetBulk operations cannot provide values for all the variables in a list, the agent provides partial results.

2.3 SNMPv3 Operations

SNMPv3 protocol operations are the same as defined for SNMPv2c.



SNMPv3 message format

-------------------------

/|\ | msgVersion |

| |-----------------------|

| | msgID |

| |-----------------------|

| | msgMaxSize |

| |-----------------------|

| | msgFlags |

scope of |-----------------------|

authentication | msgSecurityModel |

| |-----------------------|

| | | /-------------------

| | msgSecurityParameters | / | contextEngineID |

| | | / |-----------------|

| |-----------------------|/ | contextName |

| /|\ | | |-----------------|

| | | | | |

| | | | | |

| scope of | scopedPDU | | |

| encryption | | | |

| | | | | PDU (data) |

| | | | | |

\|/ \|/ | | | |

-------------------------\ | |

\ | |

\ | |

\-------------------

The SNMPv3 message consists of the following fields.

1. msgVersion - The SNMP message version. A value of 0 means SNMPv1 message, 1 means a SNMPv2c, 2 means a SNMPv2 and 3 means a SNMPv3 message respectively. The value of message version is used to choose between the different message processing models (v1, v2c or v3) available in the SNMP engine/entity. This value is 3 for a SNMPv3 message.



The following fields are part of only the SNMPv3 message and are not available in the v1 or v2c message.

2. msgID - The SNMP message identifier. This is the unique ID associated with the message. The msgID field is different from the reqID field available in the PDU. It is possible that a received PDU that is part of a message cannot be decoded due to mismatch in security parameters between the SNMP entities. The msgID is used to relate the request with a response during a transaction.

3. msgMaxSize - The maximum size of the SNMPv3 message the requesting SNMP entity will accept.

4. msgFlags - The msgFlags in the SNMPv3 message contains the message security level. The bit 0 of msgFlags is used to indicate whether a message is authenticated or not. The bit 1 is used to indicated whether a message uses privacy or not. The bit 2 is used to indicate to the receiving SNMP entity whether a report PDU is expected for the message (in case the message is dropped or a response cannot be generated)

5. msgSecurityModel - This field indicates the security model used to generate the message. The SNMPv3 standard recommends the use of USM security model. (This field has a value of 3 when USM is used)

6. msgSecurityParameters - The security model dependent security parameters. For the USM security model, this field contains the authentication parameters and the privacy parameters. For a AuthPriv message the authentication parameters has the digest computed for the message using the authentication protocol applicable for the USM entry and the privacy parameter has the salt generated while encrypting the message using the privacy protocol applicable to the USM entry.

7. contextEngineID - Within an administrative domain, the contextEngineID uniquely identifies an SNMP entity that may realize an instance of a context with a particular contextName.

8. contextName - A contextName is used to name a context. Each contextName MUST be unique within an SNMP entity

9. PDU - The SNMP PDU (Protocol Data Unit) used for communication between the peer SNMP entities. The SNMP request id, error status, variable bindings etc. are encapsulated in the PDU. There are different types of SNMP PDU like GetRequest-PDU, GetNextRequest-PDU, GetBulkRequest-PDU, Response-PDU, SetRequest-PDU, Trap-PDU, InformRequest-PDU, SNMPv2-Trap-PDU, Report-PDU etc. The exact format of the PDU (the different fields inside the PDU) depends on the PDU type.



3. Comparative overview between different versions of SNMP

The SNMPv1 and v2c protocols, which have a wide deployment base covers the following

• A platform independent data definition syntax - A subset of Abstract Syntax Notation 1 (ASN.1)

• A platform independent data transfer notation - Basic Encoding Rule (BER) • Communication between the peer entities - SNMP communication protocol

with message formats, message types etc o Message contains the SNMP protocol version o Message contains the community string which is used to provide some

security • Guidelines for definition of management data - The Structure of Management

Information • Management data definition repository - various MIB files

SNMPv3 builds on top of the above to provide a secure environment for the management of systems and networks. SNMPv3 covers

• Identification of SNMP entities to facilitate communication only between known SNMP entities (Each SNMP entity has an identifier called the SnmpEngineID. Each message contains SnmpEngineID. So SNMP communication is possible only if a SNMP entity knows the identity of its peer SNMP entity. Traps and Notifications are exceptions to this rule)

• Provision for the support for security models. A security model may define the security policy within an administrative domain or a intranet. The SNMPv3 protocol consists of the specification for the User based Security Model (USM).

• Definition of security goals where the goals of message authentication service includes protection against

o Modification of Information (Protection against some unauthorized SNMP entity altering in-transit SNMP messages generated on behalf of an authorized principal)

o Masquerade (Protection against attempting management operations not authorized for some principal by assuming the identity of another principal that has the appropriate authorizations)



o Message Stream Modification (Protection against messages getting maliciously re-ordered, delayed or replayed in order to effect unauthorized management operations)

o Disclosure (Protection against eavesdropping on the exchanges between SNMP engines)

• Specification for the USM security model. The USM security model consists of the general definition of different types of communication mechanisms available. They are

o Communication without authentication and privacy (NoAuthNoPriv) o Communication with authentication and without privacy (AuthNoPriv) o Communication with authentication and privacy (AuthPriv)

• A framework for definition of different authentication and privacy protocols. Currently the MD5 and SHA authentication protocols and the CBC_DES privacy protocols are supported in the USM.

• Definition of a discovery procedure to find the SnmpEngineID of a SNMP entity for a given transport address, transport endpoint address

• Definition of the time synchronization procedure to facilitate authenticated communication between the SNMP entities.

• Definition of the SNMP framework MIB to facilitate remote configuration and administration of the SNMP entity.

• Definition of the USM MIBs to facilitate remote configuration and administration of security module

• Definition of the VACM MIBs to facilitate remote configuration and administration of the access control module

The SNMPv3 focuses on two main aspects namely Security and Administration. The Security aspect is addressed by offering both strong authentication and data encryption for privacy. The administration aspect is focused on two parts namely, notification originators and proxy forwarders.

SNMPv3 defines two security-related capabilities namely the User-Based Security Model (USM) and View-Based Security Model (VACM). USM provides authentication and privacy (encryption) functions and operates at the message level. VACM determines whether a given principal is allowed access to particular MIB objects to perform particular functions, and operates at the PDU level

SNMPv1 and SNMPv2c



SNMPv2c provides several advantages over SNMPv1. SNMPv2c has expanded data types of 64 bit counter. It calls for improved efficiency and performance by introducing the get-bulk operator. Confirmed event notification is sought by the introduction of the inform operator. Richer error handling by errors and exceptions, improved sets by row creation and deletion and a fine tuned data definition language is some of the advantages it has over SNMPv1.

SNMPv1 and SNMPv3

The SNMPv1 Framework describes the encapsulation of SNMPv1 PDUs in SNMP messages between SNMP entities and distinguishes between application entities and protocol entities. In SNMPv3, these are renamed applications and engines, respectively.

The SNMPv1 Framework also introduces the concept of an authentication service supporting one or more authentication schemes. In SNMPv3, the concept of an authentication service is expanded to include other services, such as privacy.

The SNMPv1 Framework introduces access control based on a concept called an SNMP MIB view. The SNMPv3 Framework specifies a fundamentally similar concept called view-based access control.

SNMPv1, SNMPv2c and SNMPv3

Both the versions v1 and v2c lacked the following features, which are all focused on the security aspects. They are:

• Authentication • Privacy • Authorization and Access Control • Suitable remote configuration and administration capabilities for these

features.

The SNMPv3 was formed mainly with a concern of addressing the deficiencies related to security and administration



An example of IES-708-22A configuration

The IES-708-22A is an 8-port G.SHDSL device. The IES-708-22A aggregates traffic from 8 SHDSL lines to two Ethernet ports, and the eight G.bis ports can be bonded together to provide up to 40 Mbps symmetric bandwidth to subscribers. Moreover, with different F/W, the IES-708-22A can act as STU-C or STU-R as needed.

In this example, we provide 20.4 Mbps symmetric bandwidth to subscribers by bonding five 4M ports. We will use the built-in web configurator to configure the two IES-708-22As.

1. Bonding Overview

Bonding combines multiple ports into a logical link. This lets the IES-708-22A transmit at higher bandwidths over longer distances. In addition, bonding is a cheaper alternative than installing fiber.

Bonding can occur at the physical level or at the cell/packet level. The IES-708-22A can bond ports at the ATM-cell level.

• ITU G.bond defines bonding standards for DSL connections. • ITU G.998.1 defines bonding standards for ATM networks.

IES-708-22A (STU-C)

192.168.1.1

P-791H

P-793H

2-wire Router

4-wire

Branch 1

In this example, we provide 20.4Mbps symmetric bandwidth to subscribers:

- Bond 5 ports (10-wire)

- 4096 Kbps per port

Headquarter/Telco Operator

Branch 2

Branch 3

10-wire

IES-708-22A (STU-R)

192.168.1.100



2. Configure the IES-708-22A in STU-R mode

1) System login.

Connect to the IES-708-22A via Internet browser. The default IP address of IES-708-22A is 192.168.1.1. Enter the default username and password to access the device:

Username: admin Password: 1234

The Status screen is the first screen that displays when you access the web configurator.



2) Check STU-R/STU-C mode.

With different firmware uploaded, the IES-708-22A can act as either a STU-C or a STU-R. Hence, firstly click Basic Setting > System Information to check the System Name field. It displays the device’s model name, including STU-R/STU-C mode.



3) Set the IES-708-22A’s IP address to 192.168.1.100.

In the navigation panel, click Basic Setting > IP Setup. The IP Setup screen appears. Type 192.168.1.100 in the IP field and then press the Apply IP setting button. Use the new IP address to log into the web configurator again.



4) Create a DSL profile.

Click Basic Setting > xDSL Profiles Setup. Type a name for the profile. Here is an example of 4 Mbps (4096 Kbps) DSL profile.

a. Enter 4096 in the Max Rate field and 196 in the Min Rate field. b. Select annex_b from the Annex Mode drop-down list box to use G.992.1 Annex

B. c. Select lp_off from the Line Probing Enable Mode drop-down list box to shorten

connection setup time. d. Click Add to create the profile.



5) Create a VC profile.

Click the VC Profile link in the right upper corner of the Port Profile screen. Type a name for the profile. Here is an example for data traffic.

a. Select LLC from the Encap drop-down list box. b. Select UBR from the Class drop-down list box. c. In the second field of PCR, type 15527 (Kbps). The system will automatically

compute the number of ATM cells per second. d. Enter 0 in the CDVT field. e. Click Add to create the profile.



6) Configure the DSL ports.

Below we will assign the DSL profile to port 1, port 2, port 3, port 4 and port 5. Firstly we assign the profile to port 1.

a. Click Basic Setting > xDSL Port Setup on the navigation panel, and then click port 1’s index number.

b. Click to select the Active check box. c. Select the 4M DSL profile from the Profile drop-down list box. d. Click Apply.

Click Basic Setting > xDSL Port Setup on the navigation panel. You can see that port 1’s profile is changed from DEFVAL to 4M. Do the following to copy the profile from port 1 to the other four ports.

a. Select port 1 from the drop-down list box. b. Click to select the Profile check box.



c. Click Paste and the following screen appears. Select port 2, port 3, port 4 and port 5, and then click Apply to paste.



7) Configure settings of PVC.

Click Basic Setting > xDSL Port Setup on the navigation panel, and then click the VC Setup link in the right upper corner.

Do the following to remove the PVC of 0/33 on port 1.

a. Select the channel’s Select radio button. b. Click Delete.



c. Click OK to remove the PVC from port 1. The following screen appears. d. Select port 1, and then click Apply to delete the channel.

Do the following to create a PVC of 8/35 on port 1.

a. Select port 1. b. Click to select the Super Channel check box. c. Type 8 in the VPI field and 35 in the VCI check box. d. Select DATA_LLC from the DS VC Profile drop-down list box. e. Click the Add button to create the PVC.



The PVC of 8/35 on port 1 is created.



8) Use G.bond to bond the five ports.

a. Click Basic Setting > G.bond on the navigation panel. b. Type a name in the Bond Name field for the bond. c. Select the Member check boxes of port 1, port 2, port 3, port 4 and port 5. d. Click the Add button to add the bond.

You can use the G.bond Status screen to look at the status of each port in each bond. To open this screen, click Basic Setting > G.bond > G.bond Status.

-: This port is not a member of the bond.

V: This port is sending and receiving information in the bond.

T: This port is only sending information in the bond.

R: This port is only receiving information in the bond.

X: This port does not have a DSL connection.



Click Basic Setting > xDSL Port Setup > VC Setup. You can see the five ports are bonded into one logical link.



9) Save your configuration.

Click Config Save > Config Save on the navigation panel, and then click the Save button to save your configuration to nonvolatile memory.



3. Configure the IES-708-22A in STU-C mode

1) System login.

Connect to the IES-708-22A via Internet browser. The default IP address of IES-708-22A is 192.168.1.1. Enter the default username and password to access the device:

Username: admin Password: 1234

The Status screen is the first screen that displays when you access the web configurator.



2) Check STU-R/STU-C mode.

With different firmware uploaded, the IES-708-22A can act as either a STU-C or a STU-R. Hence, firstly click Basic Setting > System Information to check the System Name field. It displays the device’s model name, including STU-R/STU-C mode.



3) Create a DSL profile.

Click Basic Setting > xDSL Profiles Setup. Type a name for the profile. Here is an example of 4 Mbps (4096 Kbps) DSL profile.

e. Enter 4096 in the Max Rate field and 196 in the Min Rate field. f. Select annex_b from the Annex Mode drop-down list box to use G.992.1 Annex

B. g. Select lp_off from the Line Probing Enable Mode drop-down list box to shorten

connection setup time. h. Click Add to create the profile.



4) Create a VC profile.

Click the VC Profile link in the right upper corner of the Port Profile screen. Type a name for the profile. Here is an example for data traffic.

f. Select LLC from the Encap drop-down list box. g. Select UBR from the Class drop-down list box. h. In the second field of PCR, type 15527 (Kbps). The system will automatically

compute the number of ATM cells per second. i. Enter 0 in the CDVT field. j. Click Add to create the profile.



5) Configure the DSL ports.

Below we will assign the DSL profile to port 1, port 2, port 3, port 4 and port 5. Firstly we assign the profile to port 1.

e. Click Basic Setting > xDSL Port Setup on the navigation panel, and then click port 1’s index number.

f. Click to select the Active check box. g. Select the 4M DSL profile from the Profile drop-down list box. h. Click Apply.

Click Basic Setting > xDSL Port Setup on the navigation panel. You can see that port 1’s profile is changed from DEFVAL to 4M. Do the following to copy the profile from port 1 to the other four ports.

d. Select port 1 from the drop-down list box. e. Click to select the Profile check box.



f. Click Paste and the following screen appears. Select port 2, port 3, port 4 and port 5, and then click Apply to paste.



6) Configure settings of PVC.

Click Basic Setting > xDSL Port Setup on the navigation panel, and then click the VC Setup link in the right upper corner.

Do the following to remove the PVC of 0/33 on port 1.

e. Select the channel’s Select radio button. f. Click Delete.



g. Click OK to remove the PVC from port 1. The following screen appears. h. Select port 1, and then click Apply to delete the channel.

Do the following to create a PVC of 8/35 on port 1.

f. Select port 1. g. Click to select the Super Channel check box. h. Type 8 in the VPI field and 35 in the VCI check box. i. Select DATA_LLC from the DS VC Profile drop-down list box. j. Click the Add button to create the PVC.



The PVC of 8/35 on port 1 is created.



7) Use G.bond to bond the five ports.

e. Click Basic Setting > G.bond on the navigation panel. f. Type a name in the Bond Name field for the bond. g. Select sid8 from the SID drop-down list box. h. Select the Member check boxes of port 1, port 2, port 3, port 4 and port 5. i. Click the Add button to add the bond.

You can use the G.bond Status screen to look at the status of each port in each bond. To open this screen, click Basic Setting > G.bond > G.bond Status.

-: This port is not a member of the bond.

V: This port is sending and receiving information in the bond.

T: This port is only sending information in the bond.

R: This port is only receiving information in the bond.

X: This port does not have a DSL connection.



Click Basic Setting > xDSL Port Setup > VC Setup. You can see the five ports are bonded into one logical link.



8) Save your configuration.

Click Config Save > Config Save on the navigation panel, and then click the Save button to save your configuration to nonvolatile memory.



You can click Home to check the status of each port. The Home screen displays a port statistical summary with links to each port showing statistical details.



FAQ What is the IES-708-22A?

The IES-708-22A is an 8-port G.SHDSL device. The IES-708-22A aggregates traffic from 8 SHDSL lines to two Ethernet ports, and the eight G.bis ports can be bonded together to provide up to 40 Mbps symmetric bandwidth to subscribers. Moreover, with different F/W, the IES-708-22A can act as STU-C or STU-R as needed.

What kind of the G.SHDSL standard does IES-708-22A comply?

• ETSI SDSL (ETSI TS 101 524 V 1.2.1) • ITU G.shdsl (ITU-T G.991.2 (2001)) • ITU G.shdls.bis (ITU-T G.991.2 (2004)) • ITU G.998.1 (ATM-based multi-paired bonding ) • RFC4319 (formerly RFC3276) SHDSL Line MIB

What is the G.SHDSL chipset of IES-708-22A?

Infineon

How many VLAN ID and Static VLAN entry does IES-708-22A supports?

• Supported VLAN ID : 256 • Each DSL port only allows joining up to 16 static VLAN entries.

What kind of the G.SHDSL.bis functionalities does IES-708-22A support?

• Line coding: 16/32 TC-PAM • Transmit power: up to 13.5 dBm • SHDSL payload format: ATM • Rate Adaptation Mode: fixed, line probing • Each port can operate in G.SHDSL mode (at most 2.3Mbps), G.bis mode (at

most 4.096Mbps) or 5.69Mbps mode bi-directionally • Annex A and annex B PSD mask • SHDSL line profile • SHDSL alarm profile



• Power backoff

What kind of the ATM layer functionalities does IES-708-22A support?

• Support Protocols: multiple Protocols over AAL5 (RFC 2684). • Support LLC and VC multiplexing modes. • Multiple PVC support • 8 PVCs per port and each PVC is configurable • PVC to VLAN mapping • 802.1p default priority • PVC with traffic class (UBR, CBR, nrt-VBR, rt-VBR) • 256 VLAN with full range VPI and VCI… • OAM F5 end-to-end loopback (ATM mode) • ATM-based multi-paired bonding (at most 8 ports can be bonded in a group)

What kind of the Ethernet functionalities does IES-708-22A support?

• RSTP • Support IEEE 802.1Q VLAN aware bridging

o Accept untagged packets from SHDSL ports o Accept tagged and untagged packets from Ethernet interface o GVRP

• Port isolation • 256 static VLAN entries (full-range VLAN ID 1~4094) • 4 K MAC address entries • MAC count limiting • MAC filtering: only selected MACs can pass through • PPPoE filtering (pass-through/filter out) • IGMP filtering (pass-through/filter out) • DHCP filtering (pass-through/filter out) • NetBIOS filtering (pass-through/filter out) • IEEE 802.1X (EAPOL) filtering (pass-through/filter out) • IP filtering (pass-through/filter out) • ARP filtering (pass-through/filter out) • Four output priority queues with packet priority scheduling • Packet prioritizing per 802.1p

o Static configuration – default priority setting o 4 priority queues per PVC (up to 4 PVCs)



• DHCP snooping • DHCP relay agent option 82 • IEEE 802.1x port-based authentication with remote radius server

What kind of the multicasting functionalities does IES-708-22A support?

• IPv4 multicast forwarding (through L2 MAC) • Static multicast membership configuration • IGMP v1& v2 snooping & IGMP proxy mode support • Shared VLAN multicast • 256 multicast groups and each group can contain 10 members • IGMP filtering profile • IGMP count limiting • MVLAN (up to 5) • DSL port multicast bandwidth control

What is the default console rate of IES-708-22A?

9600, 8bit data, no parity, stop bit=1, no flow control.

What does it mean if the ALM LED lights on?

The ALM LED lights on means the temperature and/or voltage are outside tolerance.

How to upgrade the firmware of IES-708-22A?

IES-708-22A supports using FTP and WEB GUI to upgrade the firmware. It also supports upgrading the firmware by HyperTerminal software via local console cable.

What is the configuration limitation of IES-708-22A?

Per SHDSL port limitations:

• Number of PVC: 8 • Number of Vlan: 16 • IGMP maximum group per DSL port is 16 • IGMP maximum host IPs per DSL port is 16



• IGMP maximum host IPs per Ethernet port is 1024

System limitations:

• Number of VLAN: 256 • SHDSL profile: 24 • ATM profile: 48 • SHDSL ALARM profile: 24 • IP ROUTE: 128 • Static multicast address: 32 • Igmp groups: 256 groups • MAC learning: 40k at most (4k per SHDSL port at most, 4k per ENET port at

most)

Documents

IES-708-22A FCS SUPPORT NOTE V01 071022 - Zyxel · IES-708-22A 8-port G..bis mini-DSLAM Support Notes Version 3.52 October 2007