|
Ethernet Service Protection Over External Interfaces Written by Zehavit Alon
1 Preface 1.1 Abstract Over the last few years, packet switching technologies, such as Ethernet and MPLS, have been widely adopted by the industry as the technologies of choice to replace existing networks based on circuit-switching technologies, such as SONET/SDH and ATM. Circuit-switched network technologies provide mechanisms that guarantee sub-50ms service protection for their subscribers. A similar protection level should be provided by the different packet technologies when the identical set of capabilities formerly granted to the subscriber is required, in order for packet technologies to seamlessly replace circuit technologies. The various packet technologies define different ways of protecting a service within the network. However, all the currently defined local protection methods are intra-network only and there is no standard method for protecting services against node failures over external interfaces, i.e. for protecting connectivity between attached networks.
Figure 1 illustrates a theoretical packet based network where one of the services that span several service providers is emphasized. 1.2 Abbreviations
This section describes the definitions used throughout this paper (Some definitions are accompanied by a figure to clarify the definition).
Figure 2: Border Nodes
Figure 3: External Links
Figure 4: Interconnection Zone
Figure 5: Internal Links
Figure 6: Service portal and Portal
As the communication infrastructure nowadays has a global reach, a service may extend across a network built of several domains, each of which may employ a different technology and a different protection mechanism. Domains are connected by external interfaces (EIs). The MEF has defined two major types of EIs – User to Network Interface (UNI) and External Network to Network Interface (ENNI). Service frames transit both UNI and ENNI interfaces. To enable end-to-end service protection capable of protecting against multiple failures, each domain should protect the service locally. In addition, the service should be protected in the area between the domains, that is, in the interconnection zone where the networks are connected. I.e. a mechanism for protecting services over the UNIs between the subscriber premises and the service provider domain, and over the ENNIs where different service provider domains are attached to each other is needed. While different local protection mechanisms exist and provide protection within domains, no similar standard mechanism exists to protect services between EIs. It is desirable that any protection mechanism for the interconnection zone limits the effects of component failure or performance degradation with the result that remote parts of networks remain unaffected by these events.
Currently, link protection is the only External Interface protection type the MEF explicitly specified in its technical specifications and its implementation agreements (for ENNI - MEF 26 and for UNI - MEF 20). Other mechanisms, although not precluded, are not explicitly defined. The Link Aggregation Group (LAG) is the link protection mechanism defined by the MEF for External Interfaces. LAG is an IEEE standard, initially published as 802.3ad in 2000, and re-published as 802.1AX in 2008. It enables two nodes (referred to as partners) to connect with several links, which are treated as a single logical link, and to provide (a) load sharing and (b) protection of individual links. Traffic is distributed between all available links of the LAG. In the event of link failure, the traffic from the failed link is moved to one of the other available links of the LAG. For External Interface protection, the standardized MEF definition support only 2 links allowing a LAG to be used in an active standby configuration and not in a load-sharing configuration. This is because the MEF stipulates that service data and service monitoring shall share the same fate, while in the load-sharing LAG configuration, it is possible that service monitoring shall use a different link than the one used by the service data.
Different technologies employ different techniques in order to provide intra-domain protection; however, there is no standard way to protect the area between domains. As a mechanism is required for service protection in the interconnection zone, it is necessary to analyze the criteria that such a mechanism should comply with, and define its properties. 2.1 Criteria Any mechanism providing service protection over external interfaces should stand up with the following criteria:
2.2 Properties As the External Interfaces defined by the MEF are Ethernet interfaces, it is extremely important that the protraction mechanism complies with the basic attributes defined for Ethernet. IEEE defines a list of properties that each frame must comply with in order to enable the correct operation of the Ethernet technology. These properties are listed in IEEE802.1Q section 6.5. The following parameters, which are a sub list of the one defined by IEEE, should be taken into consideration when defining the protection mechanism. (The properties that are part of the original IEEE and are not part of the sub list has little relevance to the protection mechanism and thus are not listed below): 1. Service availability – Service availability is measured as the fraction of the total time during which the MAC service is provided. Service availability is decreased when there is a failure along the data path, and is increased when this failure is overcome. One way to increase service availability, in addition to the existing methods, is to introduce a mechanism to overcome failures in the IZ. 2. Frame loss – The MAC Service does not guarantee the delivery of Service Data Units. It is highly probable that frames transmitted by a source station will reach the destination station in an uncorrupted state. Any mechanism that increases service availability in the IZ should not cause a significantly increase in frame loss. 3. Frame misordering – The MAC Service permits a negligible rate of reordering of frames with a defined priority for a specific combination of destination addresses and source addresses, transmitted on a defined VLAN. Any mechanism that increases service availability in the IZ should not introduce additional frame misordering. 4. Frame duplication – The MAC service permits a negligible rate of frame duplication. The operation of bridges introduces a negligible rate of duplication of user data frames. Any mechanism that increases service availability in the IZ should prevent additional frame duplication, and should ensure that a frame is received only once by any of its destinations. 5. Transit delay – The MAC service introduces frame transit delay that is dependent on the particular media and MAC method employed. Frame transit delay is the time that elapses between transmitting a frame and receiving it. Any mechanism that increases service availability in the IZ must not significantly increase the transit delay. 6. Maximum Service Data Unit Size – The Maximum Service Data Unit Size varies according to the MAC method and its associated parameters (speed, electrical characteristics, etc.). The Maximum Service Data Unit Size, supported by a bridge between two LANs, is the smallest size supported by the LANs. Any mechanism that increases service availability in the IZ should refrain from increasing the Service Data Unit Size. 7. Priority – The MAC service includes priority as a Quality of Service parameter. Frames with high priority may be given precedence over other frames which were received earlier. Any mechanism that increases the service availability in the IZ should handle the frames according to their original priorities and should not modify them.
3 Protection Mechnism A protection mechanism for the IZ should operate on nodes in the border of each domain and on links connecting these border nodes. It should be able to detect failures to overcome these failures. Such a mechanism should also comply with the criteria and Properties defined in2.1and 2.2. The protection mechanism should be able to operate in any External Interface and hence should be agnostic to the type of VLAN (C-VLAN, S-VLAN)
Failures in connectivity and degradations in service performance can be detected by physical means and by OAM methods defined by IEEE 802.1ag and ITU-T Y.1731. The border nodes protecting a specific service in the domain, facing a specific attached domain, are grouped in a logical entity called the service portal. (One or more service portals can be contained within one interconnection zone). The number of nodes in each service portal greatly influences the level of protection and the quality that a service is granted. A service portal containing a single node can provide only link protection and can not protect against node failure. A service portal containing two border nodes can provide better protection, as it can provide both node and link protection. Additional nodes may be added to a service portal. However, the author of this document is of the opinion that this is unnecessary, since two border nodes can provide the required functionality. Theoretically, any topology can be used for the IZ. In some cases, one topology may be more advantageous than others, while in other cases one of the other topologies may better suit the provider's needs. The topology of choice for an operator varies according to the services provided, the network span, the connectivity between domains and the distance between significant elements in the network. Different parameters influence the number of border nodes in the service portal and the number of nodes influences the number of links in the IZ, as border nodes in each service portal may or may not be connected to each other by internal links within the service portal, and may be connected in many ways to border nodes in the service portal of the attached domain. In addition, the distance between border nodes in the same service portal influences the length of internal links, while the distance between border nodes in adjacent service portals influences the length of external links. All of these variables have a meaningful impact on the chosen topology. The selected topology affects the level of protection a service is granted i.e. the delay and the propagation of faults occurring in the IZ.
In a ring topology, each border node is connected to no more than two other border nodes;
3.2.2 Hourglass topology Hourglass topology comprises border nodes connected by external links only. (The border nodes inside the service portal are not connected by an internal link). In an hourglass topology, each border node of a service portal in one domain is connected to all border nodes of the service portal in the attached domain. This connectivity provides full protection in the four nodes construct; however, every instance of component failure (including external link failure) followed by protection switching is propagated to the attached domain as it causes a change to the nodes that handle the service. Figure 9 depicts three-node, hourglass connectivity providing partial protection. Figure 10 depicts four-node, hourglass connectivity connecting two adjacent domains which provides full protection.
Figure 9: Hourglass topology with three border nodes Figure 10: Hourglass topology with two border nodes in each domain 3.2.3 Full-mesh topology In a full-mesh topology, each border node is connected to all other border nodes in the IZ. Every border node connected to all border nodes in the attached service portal by external links, and to all border nodes within the service portal by internal links. This topology is capable of isolating a link failure ensuring that it is handled within the IZ and is not propagated outside of it. Figure 11depicts a configuration with three-node, full-mesh connectivity where two adjacent domains are connected with partial protection. Figure 12 depicts four-node, full-mesh connectivity where two adjacent domains are connected with full protection.
Figure 11: Full-mesh topology with three border nodes
Figure 12: Full-mesh topology with two border nodes in each domain
4 Inter Network Service Protection mechanism One possible way in which the required protection capabilities can be provided to all external interfaces is to use the proposed Inter Network Service protection (INSP) mechanism (explained below). The proposed mechanism ensures that service traffic will always have a path through the IZ and will be able to reach the attached domain while complying with the criteria and needed properties. The proposed INSP mechanism supports all the constructs mentioned in the previous sections. The following sections and figures describe the terms and the functionality of the different entities comprising the INSP mechanism. 4.1 INSP principle of operations The INSP is responsible for ensuring that service frames are safely delivered between attached domains and it complies with the Ethernet characteristics such as in-ordered delivery and no duplications. Each domain allocates a service portal to each service that should be safely delivered between connected domains. When a service portal include more than one border node, node protection can be achieved in addition to link protection. Connectivity interruption is minimized and frame loss will be the least possible. At any point in time, only one of the border nodes in a service portal conveys traffic from the domain to the IZ and from the IZ to the domain. This border node is called the service gateway. The SG is dynamically elected by the service portal according to the status of the domain and the IZ to which it belongs. Since the domain is dynamic, the SG may change when entities inside the service portal fail and recover. As the service portal holds only one SG at any given moment it, it is guaranteed that service frames enter from the domain to the IZ and from the IZ to the domain by a single border node. As Ethernet aims to prevent frame duplication as much as possible, it is very important to keep this goal in sight when protecting an EI. Frames that are received by all border nodes other than the SG are dropped, regardless of whether they were received from the IZ or from the domain. Figure 13 depicts an example of a service and its SGs in Operator A and in Operator B.
Figure 13: Service Gateway The SG delivers the service to the IZ and receives the service from the IZ on one link only at any given time. Operating with one SG and one link ensure that service frames are not duplicated. To ensure that service traffic is co-routed inside the IZ (to enable learning), one of the two SGs is responsible for selecting the link over which traffic is conveyed to the attached domain (This SG is referred as the initiating SG). If both SGs were to select the link, the path could diverge and transmitted and received traffic would not use the same path in the IZ. The second domain expects to receive service frames over a specific link and does not need to select a link for that service. If the selected link directly connects the SGs of the attached domains, traffic received by the SG from the IZ will be forwarded directly by the SG to its domain. Figure 14 shows an example of two attached domains where the SG in one domain is connected directly to the SG of the attached domain.
Figure 14: Directly connected SGs If the selected link is connected to a border node that is not an SG, this border node will redirect received traffic to the SG in its service portal, and the SG will transmit it to the domain. Figure 15 and Figure 16 depict examples of attached domains where the SG in one domain is not directly connected to the SG of the attached domain. These examples show the SG connected through an intermediate border node via an internal link to the SG of the attached domain.
Figure 15: SGs in mesh topology not directly connected
Figure 16: SGs in ring topology not directly connected As the INSP operates per service, it is possible to define specific border nodes as the initiating SGs (select the active link) for some services, and as the SGs that accept the selected link for other services. Load sharing can be achieved by defining different border nodes as SGs for different services. The health of the IZ components is monitored by an OAM messages sent frequently enough to comply with the protection time restriction (Property 5 and 1 above). When a failure or degradation is detected, the protection mechanism is responsible for selecting an alternate link for the affected services. If the failed component is not the initiating SG, the initiating SG selects another link to transport the interrupted service traffic. If the initiating SG fails, a new SG is elected by the service portal and the new elected initiating SG selects a link. A failed SG is overcome by electing an alternate SG. A failed link is overcome by selecting an alternate link. As Ethernet aims to prevent frame missordering as much as possible (Property 3 above), it is very important to keep this goal in sight when protecting an EI. The SG (which is the only border node that handles a service) ensures that only one port is allowed to send and receive service frames at any given moment from the IZ and to the IZ. The order of operation when selecting the link over which the service will be conveyed is as follows: first disable the port that currently receives the service frame and only then enable the new port. With this paradigm of "break-before-make", frame ordering is preserved as frames are handled from one queue at a time. This method is rapid (since each border node acts independently from other border nodes and closes its active port prior to opening a new port for the service). One of the goals protection mechanism should fulfill is to minimize the effects of a failure in the IZ on the attached domains. This goal can be fulfilled for link failures when the IZ contains internal links that can be used to bypass a failed link without changing the SG, and as the SG is not changed, the attached domain is not affected. Figure 17 depicts a scenario where the topology is full mesh. The defined path in this example is A1, A1-B2, B2 (meaning border node A1 – which is the SG of operator A's service portal, the external link directly connecting A1 to B2, and B2 which is the SG of operator B's service portal). When the external link A1-B1 fails, a new path is established A1, A1-B1, B1-B2, and B2. A1 can only use the alternate, external link connecting A1 to B1. Traffic is therefore sent by A1 on this link. Traffic sent by A1 is received by B1, which is not the SG in its service portal; therefore B1 seamlessly relays the traffic over the internal link connecting B1 with B2 to B2, which is the SG of the service portal in this domain. Although the path before and after the failure differs, the SGs in both service portals were preserved and not changed. The new route that replaces the failed route uses another external link, an additional border node and an additional internal link, but there is no change regarding the domains, as the SG in both domains remains unchanged. This functionality is beneficial as it isolates the link failure in the IZ in a way that prevents the propagation of failure effects outside the IZ. On the other hand, this functionality is only supported when internal links exist between border nodes in the service portal and can relay received traffic to the SG in the service portal.
Figure 17: Bypass of external link failure in full mesh topology Figure 18 also depicts a scenario where an external link failed, but the SG is preserved in ring topology.
Figure 18: Bypass of external link failure in ring topology When possible, a bypass inside a service domain is created by the service portal. The attached service domain plays no part in this functionality. Each domain determines by itself, whether and when to use the internal links for bypass functionality. (This differs from other protection mechanisms where usage of an alternate path is determined by the edge nodes and not by the intermediates nodes.) The initiating SG selects the link that will be used for the services it supports. As the main task is to transfer traffic between domains, and one of the requirements from an EI protection mechanism is to minimize the additional delay introduced by the protection mechanism (Property 5 above), the preferred link is one of the external links which directly connects the two SGs of the attached domain. If no such external link is available, another external link is selected. If there is no available external link an internal link is selected, assuming that the other border node in the service portal is connected to the attached domain and will be able to transfer the service to the attached domain, where it will eventually reach the SG. The INSP mechanism follows all the Ethernet functionality as defined by 802.1Q and its amendments. It does not modify the frames size in order to perform the protection switching (Property 6 above), and its queuing functionality is also not modified so it continues to handle priority as defined (Property 7 above).
1. Provides a full solution for protection of external interfaces and does not rely on non standard functionality 2. Stand alone mechanism, as intra-domain protocols, mechanisms and configurations should not be modified to support the INSP. All protocols work as usual and do not require modification. 3. Minimize frame duplication 4. Minimize frame misordering 5. Guarantees the prevention of fault propagation beyond the IZ in all topologies that support this functionality 6. Scalable, as all the protected services are monitored by one message and the protection state is coordinated by one message for all aggregated services. 7. All services can be supported by one dedicated, internal link without encapsulation. When the internal link is shared by the IZ and the domain, i.e. the domain uses this link for relaying traffic inside the domain, traffic belonging to the IZ need to be distinguished from the intra-domain traffic. All the IZ traffic can be tunneled in one tunnel and do not have to have a dedicated tunnel per service on the internal link (physical or logical) for each and every service. 8. One protocol is used on all links – external and internal and the intention is to make it standard. As the same (standard) protocol is used inside and outside the portal, the mechanism allows interoperability, since it is capable of operating in a mixed environment both inside the portal and between portals i.e. it does not assume that a single vendor will be used. 9. Supports topologies such as mesh (full and partial) and ring 10. Supports physical ports as well as LAG, so that service BW can be increased as the service grows 11. Provides simple network expansion through the addition of a domain as service protection using INSP only requires the configuration of border nodes 12. Provides simple indication on the protection state
The IEEE802.1 working group has been discussing this issue since the middle of 2009. It is highly probable that a new project dealing with EI protection will be initiated in the first half of 2011. The MEF is working on defining requirements for protecting ENNI; this project is currently in the ballot phase.
It is evident to the industry that a protection mechanism is required in the IZ. The IEEE is currently discussing possible solutions that will provide a standard mechanism. The MEF is also working on defining requirements for external interfaces protection. Such a mechanism will make networks more robust and ensure that the degree of availability defined in the service level agreement is maintained. A standard protection mechanism will enable service providers to purchase equipment from several vendors and install it in the network boundaries; providers will therefore be better placed to negotiate with the vendors. In addition, it will enable gradual upgrades and replacements of single border nodes to be performed, and the uniform management of all installed equipment. 5.3 References
Set as favorite
Bookmark
Email This
Hits: 4142 Trackback(0)
Comments
(0)
You must be logged in to a comment. Please register if you do not have an account yet.
|
| Last Updated on Thursday, 20 January 2011 10:27 |
TrackBack URI for this entry
Subscribe to this comment's feed
