|
Smart Demarcation of your Carrier Ethernet Services: Using NIDs
Abstract This article describes various types of Carrier Ethernet NIDs and the deployment scenarios in which each would be used. It summarizes the NID’s value proposition to Service Providers and presents an overview of the current standards that relate to NIDs. Introduction NIDs (Network Interface Devices) are increasingly used by Carrier Ethernet Service Providers to provide intelligent demarcation of their MEF compliant services. NIDs are especially useful when the service provider does not control the entire network from UNI to UNI. In most service scenarios, the service provider purchases services from another MEN (Metro Ethernet Network) provider (referred to herein as an Out-of-Franchise Operator, or “OOF”) or from an Access network provider, where the last mile might use another technology other than IEEE 802.3 [1]. This paper discusses the different NID types and the service scenarios that may fit each of them. It also provides a brief summary of the standardization efforts taking place in IEEE 802.1 and MEF that are applicable to NIDs. Out-of-Franchise Operator (OOF) – A MEN operated by a business entity that is external to the Service Provider’s organization. A SP may choose to engage an OOF Operator when it does not have local MEN facilities to serve a Subscriber’s location. In such scenarios, the OOF Operator’s MEN is used to extend a SP’s service transparently to a Subscriber’s premise. A Service Provider (SP) engages in a business agreement with the OOF Operator and can be considered a “customer” of the OOF Operator, while the Subscriber remains a customer of the SP. The SP's MEN is connected to the OOF via E-NNI. The SP typically purchases transparent tunnel services from the OOF Operator, which abstracts the OOF Operator from the Subscriber services provided within. These services may or may not be CoS aware, but always have SLS.
Figure 1 - OOF Scenario for Delivery of an E-Tree Service NID Definitions A NID is the network element in the MEN that directly connects to the Customer's Equipment (known as CE). When providing connectivity between CEs over a MEN, the network elements that provide the connectivity (including the NIDs) are the responsibility of the Service Provider. Since the service provider may provide a Service Level Agreement (SLA) to the Subscriber, it is essential to have a network element to enforce the traffic contract, measure the performance and ease in troubleshooting. From an architecture point of view, NIDs can operate at any combination of the following layers: 1. Transport Layer – This layer is service unaware and provides only the link level connectivity and OAM 2. Tunnel Service Layer – This mode assumes that there is a tunnel through an operator's network that reaches the service provider's MEN 3. Ethernet Service Layer – The NID is service aware and provides some of the MEN functionality (part of the UNI-N functionality)
The MEF defines 5 NID types as follows: 1. Transport NID 2. Service NID 3. Tunnel NID 4. Tunnel & Service NID 5. Hybrid NID
Transport NID This may be conceived as the most basic type of NID. It provides the termination of the transport layer of the MEN. This type of NID is similar to a TPMR defined in IEEE 802.1aj [2]. This NID is administratively controlled by the Service Provider. Service NID A Service NID is aware of the different services provided by the MEN to a Subscriber. It performs some of the UNI-N functionality [refer to [3] for a complete list of UNI-N functions] like enforcement of the BW profile, frame adaptation, mapping, etc. It also provides Service level OAM consistent with IEEE 802.1ag [4], ITU-T Y.1731 [5] and MEF SOAM IA [6], which can be used for both fault management and performance management. This NID is administratively controlled by the Service Provider. Tunnel NID When the Service Provider does not have access facilities to the customer's premise, it may contract with an Out-of-Franchise operator to tunnel a service through the OOF MEN to the customer. The OOF Operator deploys a Tunnel NID at the customer premise, which terminates a Terminating Tunnel service offered to the Service Provider. In this case, the Tunnel NID is service unaware and the UNI-N functionality is performed at the Service Provider’s MEN in a functional entity referred to as a Virtual UNI (V-UNI). The tunnel NID is aware of the tunnel service and performs the required adaptation, policing and optionally CoS handling for the tunnel service. t provides OAM for the tunnel level for both fault management and performance management. This NID is administratively controlled by the OOF Operator. Tunnel & Service NID The Tunnel & Service NID is a combination of the previous two types of NIDs in a single device. This NID performs some of the UNI-N functions on the service level, before the Subscriber traffic enters the tunnel. The service awareness in the NID may yield better handling of complex service scenarios, as it can guarantee the CoS and BW profiles before the traffic enters the tunnel. It also allows the for the implementation of SOAM entities right at the physical demarcation point, which may provide superior information on per-service performance. The Tunnel & Service NID is owned and administratively controlled by the OOF Operator. When the Service Provider contracts with the OOF Operator for a Tunnel Service using this type of NID, the Service Provider asks the OOF Operator to set Subscriber service level attributes on this NID. By doing this, the OOF Operator is implementing some of the UNI-N functions on behalf of the Service Provider. Hybrid NID A Hybrid NID is basically the same as the Tunnel & Service NID, but adds an additional layer of management functionality. The Hybrid NID allows the OOF Operator to relinquish administrative control of the NID’s UNI-N functions to the Service Provider through a secure management channel. The Hybrid NID allows the Service Provider to provision and administrate the UNI-N functions on the NID remotely, as if the UNI-N functional entities were owned by the Service Provider. The OOF Operator need not get involved in the provisioning and administration of the UNI-N functions. It simply turns over control of these functions to the Service Provider. It should be noted that the OOF Operator can always take control of any part of the NID at any time (including the UNI-N functional entities, if need be or if assistance is requested by the Service Provider). The OOF Operator administratively controls the Tunnel service entities in order to deliver the Terminating Tunnel Service to the Service Provider. Service Scenarios 1. Single MEN, with CEs directly connected to MEN's edge. This service scenario is illustrated in Figure 3:
The CEs are directly connected to a single MEN providing the service. The NIDs may provide the entire UNI functionally required from the MEN and, in fact, replace the metro-edge switch. This implies that a Service NID is required. In this scenario, each customer has a dedicated NID and the SP's domain of responsibility is from NID-to-NID.
Some of the CEs are not directly connected to the MEN, likely because the service provider does not have presence at the CE's location. The right most NID in Figure 4 is part of an access network (which is not a MEN). The NID could be a Transport NID, thus leaving the entire UNI-N functionality to the metro edge switch. It could also be a Service NID, as there is a single service provider responsible for the service. The SP must ensure that the access network provides performance guarantees that meet the SLS promised to the Subscriber. This access network is assumed to have no affect on the service frames it carries. 3. OOF MEN. This service scenario is illustrated in Figure 5. Figure 5 - OOF Scenario The right most NID in figure 5 resides in an OOF MEN. The SP's MEN and the OOF MEN are connected over an E-NNI interface and there is a tunnel between the NID and the E-NNI. Three types of NIDs could be used for this service scenario: a) Tunnel NID – Creates a non-service aware tunnel and leaves the UNI-N functionality to a virtual UNI within the SP's MEN. b) Tunnel and Service NID – Some service awareness is added to the NID before the traffic enters the tunnel. This could facilitate providing different services while measuring the per-service performance and providing different SLS, likely using traffic management techniques. c) Hybrid NID – Similar to the previous case, but allows both MEN administrators to control specific aspects of the NID. Benefits of NIDs to SP and operators Intuitively, one might assume that it is not in the SP’s interest to install a piece of equipment at the customer premise and incur an additional CAPEX cost. However, NIDs not only improve the Subscriber's experience, they ease in troubleshooting, which in turn reduces the SP’s OPEX. The OPEX savings quickly compensates for the cost of deploying a NID. In many cases, installing a NID that performs aggregation to a single (say 1 GbE) port of the edge switch / router actually translates into better scalability and a better normalized cost per port for a service provider. One example would be a customer purchasing a low bit-rate SLA. In such a scenario, 10 to 20 customers could be served by one port of the metro edge equipment without oversubscribing the service. In the Out-of-Franchise scenario, the decision to deploy a NID is not a matter of scalability and cost. It is an essential building block to providing the end-to-end service. The NID may provide the traffic contract assurance, as it manages the various traffic types and provides the QoS required by sensitive applications. The NID provides the mechanism for end-to-end OAM for both fault management and performance management. It offers great value in its ability to measure the per-service performance and by proactively identifying when the SLA may be breached. In addition, when problems occur, the NID provides the ability to diagnose and localize the fault in the network layer in which the problem occurs. This is of critical importance, especially when multiple service entities are involved. When spanning over access networks that are not as sophisticated as MENs in terms of their inherent QoS capabilities, fast service restoration and security, the NID can initiate tunnels across this access network, facilitating the services sold by the SP and thus making the access network as transparent as possible. Related Standards The IEEE P802.1aj project specifies a special type of two-port Bridge, known as a Two-Port MAC Relay (TPMR), which can be used as a demarcation device for Service Providers. A TPMR is intended to have a simplified Forwarding and Filtering process compared to a traditional Q-Bridge, so that it may transparently forward Subscriber frames between its ports without “learning” MAC addresses. It is also the first IEEE P802.1 system that makes use of a VLAN-unaware bridge component. This new bridge component enables Service Providers to deploy this device without the trouble of having to administratively configure the Subscriber’s CE-VLANs on the TPMR. This allows for quick turn-up by field technicians and installers. The TPMR includes new technology that allows the Service Provider to securely manage the device remotely. The TPMR can be configured such that management packets transmitted by the Service Provider element management systems destined for a TPMR will not be forwarded to the Subscriber’s network. The TPMR does not participate in most Q-Bridge protocols, but does define a new MAC Status Protocol, which will help propagate MAC layer status notifications between bridges participating in this protocol. The TPMR is a low-cost device that can be used to diagnose connectivity issues right up to the Subscriber’s premise. The TPMR is not Subscriber service aware in order to eliminate the operational overhead associated with the deployment of traditional Q-Bridges as demarcation devices. The MEF NID Requirements & Framework Technical Specification will provide specifications for two types of NIDs: the Service NID and the Hybrid NID. The Service NID builds on the work of the IEEE P802.1aj by adding Subscriber service awareness to a TPMR-like device. The Service NID allows Service Providers to configure SOAM Maintenance Points (MPs) for each of the Subscriber’s CE-VLANs. These MPs can be used both for fault management and performance monitoring. The Hybrid NID, as discussed in this paper, can be used to terminate the tunnel layer and provide a complete set of UNI-N functions on an OOF network to a Service Provider. This is a relatively complex NID compared to the Service NID, as it incorporates all the architectural elements of a PE and introduces new technology to allow both a OOF Operator and a Service Provider to securely manage the device. References [1] IEEE Std 802.3™-2005, Information technology – Telecommunications and information exchange between systems – Local and metropolitan area networks – Specific requirements – Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications, 9 December 2005. [2] IEEE P802.1aj/D3.1, IEEE Standards for Local and metropolitan area networks—Virtual Bridged Local Area Networks, Amendment 8: Two-Port Media Access Control (MAC) Relay, 3 October 2008. [3] Metro Ethernet Forum, MEF 12.1 Draft 0.3, Carrier Ethernet Network Architecture Framework, Part 2: Ethernet Services Layer, 5 February 2009. [4] IEEE Std 802.1ag™-2007, IEEE Standards for Local and metropolitan area networks—Virtual Bridged Local Area Networks, Amendment 5: Connectivity Fault Management, 17 December 2007. [5] International Telecommunication Union, Recommendation Y.1731, Series Y: Global Information Infrastructure, Internet Protocol Aspects and Next-Generation Networks, Internet Protocol Aspects – Operation, administration and maintenance, OAM functions and mechanisms for Ethernet based networks, May 2005.\ [6] Metro Ethernet Forum, Service OAM Performance Monitoring – Phase 1 Implementation Agreement, Draft 3.0, January 29, 2009. About the Authors Ayal Lior was active and well-known in the technical work of MEF between the years 2005 - 2008. Mr. Lior was twice commended for outstanding contribution to the MEF. He has over 12 years of experience in networking and system architectures, system design, protocol design and an intimate knowledge of Ethernet and TCP/IP. Mr. Lior is a Traffic Management expert (design, implementation, deployment) both in Software and Hardware. He can be reached at
This e-mail address is being protected from spambots. You need JavaScript enabled to view it
Marco Mascitto is the President and founder of Telion Consulting Inc., a management consulting firm offering technology and product development services to equipment vendors specializing in broadband solutions. Through his sponsorship by Canoga Perkins Corp., Mr. Mascitto has contributed to a number of MEF Technical Specifications, and is a co-editor of the MEF NID Requirements & Framework draft. Mr. Mascitto has over a decade of experience in network systems design and development, is a member of the IEEE, and holds a Bachelor of Computer Engineering degree from McGill University (Montreal, Canada). He can be reached at This e-mail address is being protected from spambots. You need JavaScript enabled to view it , or at +1-514-747-2444. Trackback(0)
Comments
(10)
Well, it will need to be service aware and map incoming traffic to EVCs.
Votes: +0
Potentially will need to enforce the bandwidth profile. One may also want to shape the traffic, thus require queuing, shapers etc. If you can do that, you are almost capable of certifying this NE as MEF 9 / 14 compliant. Ayal report abuse
vote down
vote up
Yes, then you need NID functionality. Also wonder what's the functional difference between a NID from a NID vendor and an OAM-capable L2 switch (low port density) from a (traditional) switch vendor?
Votes: +0
Regards, Peng report abuse
vote down
vote up
But in some cases (e.g. OOF, Access network) the SP who can put a need in the customer premise does not own the edge switch of the operator’s network
Votes: +0
Ayal report abuse
vote down
vote up
This is absolutely a good article with no doubt. My understanding is that from the 'functionality' point of view, yes, you need 'NID'; but the 'NID functionality' can be deployed/implemented either in special so-called NID devices, or in OAM-enable L2 edge/access switches.
Votes: +0
Regards, Peng report abuse
vote down
vote up
An excellent and concise summary of an other somewhat confusing topic
Votes: +0
 Thanks Anthony report abuse
vote down
vote up
I consider the NID to be an essential component of an infrastructure to deliver Ethernet Services. It is always part of my design recommendation to any carrier and/or ISP.
Votes: +0
In fact, it is the way to monitor certain SLAs and isolate certain faults. - How will a carrier be able to protect itself from a customer that has a misconfiguration on its CE that is causing errors or lines resets or injecting delay, and so on, and is complaining the SLA is not been in comply? (duplex and MTU anyone?) - How can a carrier know if the links is down because the customer decides to shutdown its CE over the weekend or because there was a fiber cut? (yeah, I've seen that). More general: How does a provider distinguish between line failures and CE failures? - How can a carrier distinguish over path errors vs customer hardware generating errors? - How can a carrier be able to do loopbacks test on per-service/per-vlan if there is no demarcation between the carrier and the customer? - If the customer has a contracted SLA with real-time monitoring, how does he knows if it is his CE failing or the providers line? Now, I also understand that the market need cheaper NIDs following the standards. It is very difficult to justify the cost of a NID that might range from $400 to $5000+ if you are only considering CAPEX and even harder if the profit margins are low. It is part of network/solution designers/engineers or operation department or consultants or the industry, to demonstrate the benefits of the NIDs and the standards available. (...and make life easier for everyone) _W report abuse
vote down
vote up
Good point, Ayal.
Votes: +0
Looks like more marketing efforts are needed to educate SPs in developing countries to learn the benefits of adding NIDs to their networks. Thanks, Tao report abuse
vote down
vote up
Hi Tao,
Votes: +0
One reason of putting NIDs relate to regulations or CAPEX saving where the SP cannot or does not want to roll fibers to the customer’s premise. However, other scenarios might be applicable outside the U.S / Europe. If you have a single customer on a certain area, you may not want to put a pricy Switch out there. Another use case would be international service where again the SP does not have access to the customer premise. My 5 cents, Ayal report abuse
vote down
vote up
Great article.
Votes: +0
I guess if the main purpose of NID is to reduce OPEX, only developed counties need such devices while developing countries don't because labor cost is so low that truck rolls don't really cost that much. That probably explains why there are huge demands in North America and Europe but none in China and Brazil. I am not sure about the other BRIC countries though: India and Russia, anyone knows? Thanks, Tao report abuse
vote down
vote up
You must be logged in to a comment. Please register if you do not have an account yet.
|
| Last Updated on Thursday, 05 November 2009 19:53 |
TrackBack URI for this entry
Subscribe to this comment's feed
It looks to me that in practice NID from NID vendors focuses on the 'test' functionality a bit more than the 'switching' functionality when comparing with a traditional L2 OAM-capable switch. A practical NID usually has 1) hardware-based OAM; 2) EMS for E2E test show and provisioning; 3) (optional) on-board storage to store some test data/results if possible.
Regards,
Peng