Ethernet OAM veya service OAM adında anlaşılacağı gibi ethernet devrelerinde, carrier ethernet, OAM özelliklerinin standart hale getirilmiş şeklidir.
Kabaca EOAM, E-LMI gibi fiziksel link üzerinde çalışan point-to-point prokoller ile beraber ( yeni standarlar ile birlikte bu protokollerin bazılarınında müşteri devrelerinde uçtan uca taşınması gerekmektedir) CFM gibi uçtan uca kullanılabilecek özellikleri içerir.
Ethernet Link OAM IEEE 802.3ah :
Belli bir link üzerinde monitoring ve hata bildirimi için kullanılır ve sadece söz konusu link üzerinde çalışır (single hop, fakat bazı UPE cihazları bunları tunneliyebilmektedir. user tarafından gelen bilgileri SP tarafına gönderebilen cihazlar vardır).
Söz konusu link için;
– Link monitoring : Hattın tek tarafını veya iki tarafını.
– Remote Failure Indication : Power loss, link down (admin), reboot vb.
– Remote Loopback Control : Karşı ucu data loop verdirmek için. 802.3ah Loopback fonksiyonu source ve destination MAC adres değişimini içermez. Dolayısı ile ethernet tester vb. işlevler için bunların değişimi gerekir. Her vendor’ın bu konuda desteği farklı olabilir. Aryıca loop’un ne tarafa doğru verildiği önemlidir, external veya internal loopback. external loopback fiziksel hattın ucunda veya internal, bridge fonksiyonunda sonra. Her iki işlemdede Source ve Destination MAC adresi değiştirilir.
Hattın iki ucu Link OAM için komşuluk kurarlar ve link oam yeteneklerini bir birlerine iletirler. Dolayısı ile bir discovery süreci vardır. İstenilen yeteneğin olmaması durmunda link error duruma sokmak gerekli bir özellik olabilir (IOS XR action capabilities-conflict or action discovery-timeout). Multicast Destination (0180.c200.0002) ve Ether-Type (8809).
Connectivity Fault Management (CFM) IEEE 802.1ag ve ITU-T Y.1731 : Uçdan uca ethernet devresinin kontrolünü sağlayan bir protokol bütünüdür. IP ping ve traceroute gibi L2/ethernet seviyesinde ping ve traceroute benzeri OAM özelliklerini tanımlar.
Kullanıcı data’sı ile birlikte iletilir. Dolayısı ile CFM mesajlarından anlamayan bir cihaz normal kullanıcı data’sı şeklinde algılayıp iletimini sağlar. CFM mesajları DS MAC adresleri veya Ether-Type (0x8902) ile filtrelenebilir.
Bir cihazın söz konusu portunun, özelik ile UPE veya NPE gibi qiq ve pw kullanılan cihazlarda ne zaman CFM mesajlarının işleneceği veya transparent olarak iletileceği cihaz üzerinden yapılan yapılandırma ile direk ilgilidir.
Örnek olarak pw tanımı olan bir portta CFM yapılandırılmış olsun.
interface GigabitEthernet0/0/1/0.10 l2transport encapsulation dot1q 10 rewrite ingress tag pop 1 symmetric ethernet cfm mep domain MY_DOMAIN service TEST_SERVICE mep-id 1 !
Bu portta tek bir vlan girilmiş. Buda genel olarak müşteri devresi için tanımlanan S-VLAN’dır. Eğer CFM paketleri S-VLAN ile gelir ise port CFM tarafından işlenir. Gelmez ise, yani C-VLAN ile gelirse başka bir deyiş ile C-VLAN altında yapılandırılmış ise port tarafından işlenmez. Zira port CFM mesajlarını tek bir vlan tag’i ile beklemektedir. Yukarıdaki yapılandırma genel olarak NPE bulunur. Müşterinin CFM mesajları genelde, CPE tarafından untagged, port based gönderilmediği sürece, kendi vlanları içerisinde olur yani C-VLAN ile taglenmiş olur. Bu durumda müşteri NPE’yi domaini göremez. Bu durumda başka bir operatöre sağlanan carrier ethernet devrelerinde bir sorun olmaya bilir. Çünkü bir alt operatörün UPE bakan interfacinde genelde untagged olarak CFM konfig etmesi beklenir. Tagged olarak göndermesi durumunda kendi service vlanını kullanması söz konusudur. Buda C-VLAN + S-VLAN + S-VLAN şeklinde bir servis olur. Dolayısı ile genel olarak UPE tarafında ilgili yeteneğin olması beklenmektedir. CFM support for customer vlan.
CFM ve Y.1731 farklı terimler kullanıyor olabilir. Y.1731 yapılandırması yapılan bir cihaz, CFM yapıladırması yapılan bir cihaz ile iletişim kuramıyor olabilir. Örnek olarak Y.1731’de MD name tanımlı değildir. null olması beklenir. Bazı Y.1731 yapılandırması yapılan cihazlar, null olmayan CFM mesajlarınıda tanır iken, bazıları tanımızlar! Bu gibi tanım farklılıklarına dikkat edilmelidir.
Temel mekanizmalar;
Maintenance Domain (MD) : Network yönetim açısından domainlere ayrılabilir. Bir network’de birden fazla domain olabilir. Domainler iç içe geçebilir fakat hiç bir zaman kesişemez. En fazla 8 adet iç içe geçen domain’e izin verilir (0..7). Maintenance Level numarası ne kadar düşük ise öncelik o kadar fazladır. Level 0 link level için ayırmak uygun olabilir. Level 7’de son domain olduğu için son müşteriye ayrılabilir. CFM mesajları bulundukları domain’in maintenance level seviyesini içerir.
Maintenance Associations (MA) : MA belli bir MD içerisindeki service monitor ederler. Aşağıdada görüldüğü gibi bir müşteri servicei için birden fazla MA oluşturulabilir. Müşteri kendi için bir MA oluşturur. Her bir domain’de kendi yönetimlerinde olan hatlar için bir MA oluşturabilir. Cisco dökümanlarında MA aynı zamanda CFM servisleri olarakda geçerler. ITU-T Y.1731 ise Maintenance Entity Groups, MEG, olarak geçer.
Maintenance Association Points (MP) : (MP veya MEP)
– Maintenance Association End Points : CFM mesajlarına cevap veren veya gönderen noktalar. MA’ların uç noktlarıda denilebilir. MEP’lerin CFM mesajlarını işlemesi bulundukları seviye ile ilgilidir. MEP olarak yapılandırılan portlar sadece yapılandırıldıkları MEP’lerin mesajlarına cevap verirler. MEP kendi seviyesinden büyük leveları işlemez (sayı olarak düşük). Kendi level’ından gelen mesajları ise bulunduğu yöne göre işler (UP MEP/DOWN MEP).
– Maintenance Association Intermediate Point : MA’ların ara noktalarıda denilebilir. Kendi seviyelerindeki CFM mesajlarına cevap verirler.MIP’ler özel olarak konfigure edilmezler. Standartlara uygun olarak otomatik olarak oluşturulabilirler. Fakat bu otomatik oluşturmanında bir kuralı vardır. Aşağıda ASR9000 IOS XR Otomatik MIP yaratma kuralı vardır. Genelde carrier ethernet için kullanılan UPE’ler de daha fazla özellik bulunur.
MEP’ler kendi içinde ikiye ayrılırlar;
– UP MEP : Portun fiziksel tarafa bakan ucunda değilde, bridge-relay fonksiyonuna bakan, yani içeri bakan tarafında tanımlı MEP’ler için kullınılır. Genelde UNI portlarında tanımlıdırlar (Müşterinin PE bağlı olduğu port). Layer 2 cihazlarda (switch) tanımlanır.
– DOWN MEP : Portun fiziksel tarafına doğru tanımlı MEP’ler için kullanılan terimdir. Genelde CPE tarafında PE bağlı port için tanımlanır. Layer 2 veya layer 3 portlarda tanımlanabilirler. Router ve switchlere özgüdür. Buradan routerlarda sadece DOWN MEP tanımlanabileceğini anlıyoruz. subinterface için ise encap vlan 1-4094 için.
Genel olarak kullanılan terminology aynı olmak ile birlikte ;
For IEEE 802.1ag, the terms Maintenance Entity, Maintenance Level, and Maintenance Domain have the same meaning as in ITU-T Y.1731. IEEE 802.1ag uses the term MA in the same context as Y.1731 MEG. For IEEE 802.1ag, MEPs and MIPs are the short form of MA End Points and Intermediate Points. They are functionally equivalent to ITU-T MEPs and MIPs.
olarak farklılıklar bulunabilir.
Y.1731 Performance monitoring (PM) : ITU-T Y-1731 tanımlanmış, ethernet frame delay, frame delay variation, frame loss, and frame throughput ölçümleridir.
Genel olarak mesajlar veya protokoller ;
OAM Functions for Fault Management
Ethernet Continuity Check (ETH-CC)
Ethernet Loopback (ETH-LB)
Ethernet Linktrace (ETH-LT)
Ethernet Remote Defect Indication (ETH-RDI)
Ethernet Alarm Indication Signal (ETH-AIS)
Ethernet Locked Signal (ETH-LCK)
Ethernet Client Signal Fail (ETH-CSF)
Ek olarak: ETH-TEST, ETH-APS, ETH-MCC, ETH-EXP, ETH-VSP
OAM Functions for Performance Management
Frame Loss Measurement (ETH-LM)
Synthetic Frame Loss Measurement (ETH-SLM)
Frame Delay Measurement (ETH-DM)
Bir diğer önemli konu, frame delay gibi ölçümlerin one-way ve two-way olarak ikiye ayrılmasıdır.
One-way ölçümlerde tüm hesaplama işlemleri, probe’u alan tarafda yapılır. Dolayısı ile gönderen ve alan tarafında zaman olaran bir birlerine yüksek seviyede senkronize olmalarını gerektirir. Hesaplayan taraf, delay vb hesapları alıcı tarafından probe’a eklenen timestampler üzerinden yapar. Dolayısı iki sistem arasında zaman farkı olur ise, hesaplamada da hatalar olacakdır. Özellikle negatif zaman farklarında.
Two-way ise, alıcı taraf gelen probe kendi zaman etiketlerini ekleyerek alıcıya gönderir. Hesaplamalar alıcı tarafında yapılır. Dolayısı ile zaman senkronizasyonu açısından daha az hassas bir ölçüm yapılır. Bu şekilde round-trip ölçümleride yapılmış olur.
Perfomance öçümlerinde time senkronizasyonu oldukça önemlidir. Framelere timestamp eklenmesi hardware bazında yapılmalıdır. İki uç arasındaki zaman farklı, senkronizasyon hatalarından dolayı negatif çıkarsa bu da hesaplamada hatalar oluşmasına yol açar.
Protokoller : Detaylı bilgi için: BRKNMS-2202 – Ethernet OAM: Technical Overview and Deployment Scenarios
1) Continuity Check Messages (CCM) : MEP’ler tarafından karşılıklı olarak hattın bağlantı durumunu kontrol etmek için düzenli olarak gönderilirler. Multicast olarak gönderilirler. Gönderen MEP bir karşılık beklemez. Bu şekilde MA’nın karşı ucu keşfedilmiş olur ve düzenli olarak gönderilmesi sayesinde hattın durumuda izlenir. CCM mesajını alan MEP bunu daha fazla iletmez. MIP’ler ise kendi maintenance level’larındaki CFM mesajlarını alarak, bir mesajı gönderen node’lara ait bir liste tutarlar (Söz konusu MA içerisindeki MP listesi). CC mesajları aynı zamanda dual-ended frame loss hesaplamalarında da kullanılabilir.
CCM mesajları, söz konusu MA hakkında bir çok bilgi içerir. Genel olarak bunlar, bulunduğu domain’i belirten bir domain identifier, Maintenance Domain Identifier (MDID), MDID ve bulunduğu maintenance id’nin kısa adının (short maintenance name SMAN) birleşiminden oluşan MAID, MEPID, Sequnce ID, Remote Defect Indication, the interval at which CCMs are being transmitted, the status of the interface where the MEP is operating
Peki CCM mesajları izlenerek neler tesipt edilebilir;
– Interval mismatch—The CCM interval in the received CCM does not match the interval that the MEP is sending CCMs.
– Level mismatch—A MEP has received a CCM carrying a lower maintenance level than the MEPs own level.
– Loop—A CCM is received with the source MAC address equal to the MAC address of the interface where the MEP is operating.
– Configuration error—A CCM is received with the same MEP ID as the MEP ID configured for the receiving MEP.
– Cross-connect—A CCM is received with an MAID that does not match the locally configured MAID. This generally indicates a VLAN misconfiguration within the network, such that CCMs from one service are leaking into a different service.
– Peer interface down—A CCM is received that indicates the interface on the peer is down.
Remote defect indication—A CCM is received carrying a remote defect indication.
CCM mesajlarının işlenmesi platforma göre sorun yaratabilir. Özellikle ASR 9000 gibi, bu tarz işlevleri line card’ta değilde merkezi cpu üzerinde yapan platformalarda yüksek sayıda servis için CCM performansına bakılmalıdır.
2) Loopback Message (LBM) :
Ping’e benzer bir işlevi vardır. Kullanıcı isteği ile başka bir MP’i (MEP veya MIP) sorgulamak için kullanılır. Bir çeşit Etherner Ping işlevide denilebilir. Loopback Messages (LBM) ve Loopback Replies (LBR) mesajlarından oluşur. LBM mesajları kullanıcı tarafından belirtilen bir data ile doldurulmasıda mümkündür. LBM mesajını alan MP aynı veri ile geri döner. Bu şekilde veri bütünlüğüde kontrol edilmiş olur. Ayrıca sequence numarasıda içerdiklerinden out-of-order frame hesaplamasındada kullanılabilirler. One-way delay ve jitter dışında eğer karşı uç delay ölçümlerini desteklemiyor ise Ethernet SLA konfigurasyonunda kullanılabilirler.
3) Link Trace Message (LTM) : Link Trace Messages (LBM) ve Lint Trace Replies (LBR) mesajlarından oluşur. IP Trace benzer bir işlevi vardır. IP Trace’de birden fazla istek gönderilir. Fakat LTM ile tek bir istek gönderilir, MA içerisindeki tüm MP’ler tarafından bu istek iletilir. LBM mesajları multicast’tir. MA içerisinde bu mesajı alan her MP unicast olarak kaynap MP’ye geri döner.
LTM mesajları hata durumunda oldukça yaralıdır. Hatta data durumundan sonra bile CCM mesajlarının MP’ler tarafından saklanmasından dolayı (CCM Learning Database) bile kontroller için kullanılabilir.
4) Alarm Indication Signal (AIS) :
CCM mesajlarının timeout olmasını beklemeden, hata durumunda MA’ları hızlıca hata hakkında bildirmek için kullanılır. Hata olur olmaz, MA içerisinde MP’ler tarafından CCM mesajlarına ters yönlü olarak MEP’lere doğru AIS gönderilir. MEP’ler AIS alır almaz, bir üzt domain’e AIS’i bildirler.
5) Delay and Jitter Mesarument ETH-DM :
Loopback mesajlarına benzeyen Delay Measurement Message (DMM) ve Delay Measurement Response (DMM) oluşur. One-way veya two-way delay ölçümü sağlar. Bu işlev için Time-Of-Day Syncronization ihtiyaç duyar. Sadece point-to-point devreler içindir.
ITU-T Y-1731 ile tanımlanmış iki tip delay ölçümü vardır.
– One-way ETH-DM: Delay Measurement Message (DMM) ve Delay Measurement Reply (DMR) mesajları kullanılır. Frame Delay ölçümü için karşılıklı iki ucun zaman açısından senkronizasyonu gereklidir. Hesaplamayı karşı uç yapar. Zira zaman açısından sync olunmuştur ve timestampler geçerlidir.
– Two-way ETH-DM: Two-way ETH-DM için zaman senkronizasyonu gerekli değildir. Timestamp ile işaretlemiş paket karşu uçdan geri gönderilir. Dolayısı ile ikisi arasındaki fark hesaplanır. Eğer karşı uç ile zaman senkronizasyonu sağlanmış ise iki yönlü delay’de hesaplanabilir.
6) Loss Mesarument ETH-LM :
Gerçek data’nın kaybını ölçmeye yararlar. Bu işlev için hassas bir time-of-day syncronization gerek vardır. Gönderilen frame miktarı, time-of-stamp ile birlikte karşı uca bildirilir. Karşı uçda bunu kendi verileri ile karşılaştır veya kendi verilerini yine reply-back şeklinde karşı uca bildirir. Göndirilen veri, priority-class (COS) servisi bazındada hesaplanır ve bildirilir. Sadece point-to-point devreler içindir.
Ethernet frame Loss Measurement (ETH-LM) :
– Single-ended ETH-LM
– Dual-ended ETH-LM
7) Synthetic Loss Mesarument ETH-SLM:
Gerçek data yerine, normal data akışına eklenen SLM mesajlarından oluşur. SLM mesajları aynı zamanda seq numarasıda içerir. Karşı uç’da SLR ile cevap verir. Bu cevap içerisinde SLM gönderenin seq numarası dışında kendi seq numarasıda vardır. Bu şekilde iki yönlü hesaplamada yapılabilir. ETH-LM ek olarak Multipoint devreler’de de kullanılabilir. Detaylı bilgi için
– Single-ended ETH-SLM
– Dual-ended ETH-SLM
Ayrıca vendor’ların (Vendor TLV) tanımladığı kendilerine özgü mesajlarda olabilir. Cisco Exploratory Linktrace gibi.
MEP Cross-Check :
CFM servisi CCM mesajları alınan MEP listesini tutar. Burada bir sorun olması durumunda MEP Cross-Check işlevini başlatır.
Ethernet Fault Detection (EFD) :
Diğer media tiplerinden farklı olarak, Ethernet için bir line protokol tanımlı değildir. Bunu yerine OSI pysical layer bu işlevden sorumludur. EFD ile CFM ile servisde bir sorun olması durumunda ilgili interfarce line-protocol down durumuna alınabilir. Bu şekilde layer 2 işlevleri (STP, mac address temizlenmesi) veya layer 3 routing tablolarına interface hakkındaki değişiklik yansıtılmış olur.
CFM Mesajlarının İşlenmesi :
Daha öncede belirtildiği gibi müşteride kendi CFM domain’ini çalıştırabilir. Bu durumda CFM mesajlarını işlenmesi ayrı bir konudur. Cihazların vlan tagleri ve CFM mesajları arasındaki ilişkiyi kurması, ele alması veya transparent şekilde iletmesi vb konular her vendor hatta her cihaz tipi için incelenmelidir. Cisco için Flexible Vlan tagging for CFM konusu altında incelenebilir.
Aynı şekilde LAG konfigurasyonlarındada CFM mesajlarının işlenmesi incelenmelidir.
Ek bilgi :
Dikkat ;
- Ethernet OAM link üzerindeki frame-loss, delay gibi değerler için kullanılmaz. İki taraf bir birleri ile komşuluk kurar ve hat üzerindeki kendi hatalarını karşıya raporlamak için kullanırlar. Bu sayade reboot, powerd-down (dying gasp gibi) ve benzeri hataları karşı uca gerekli önlemleri alması için yollanır. Sadece tek bir link hop boyunca iletilirler. Fakat devrenin MPLS ile iletilmesi durumunda, Ethernet OAM komşuluğunun kurulması konusu vendor notlarına bakılmalıdır. Bazen L2 protokol frame gibi karşı uca MPLS üzerinden iletilen OAM mesajarı sonucu değişik komşuluk ilişkileri olabilir.
- Y.1731, CFM üzerine performans eklentilerini getirmiştir. Başlı başına bir standarttır. Henüz tam olarak tamamlanmamıştır (büyük ölçüde tamamlanmıştır).
- Y.1731 ölçümleri için network cihazlarının time-of-day senkronizasyonu önemlidir. Burada NTP yerine daha hassas methodlar kullanılması gereklidir (hassasiyet ms ve altında). PTP, Sync E vb.
- Zaman konusunda sıkıntı olması veya gerekli protokolleri desteklememesi durumunda, ethernet cfm loopback mesajları kullanılabilir. Daha kısıtlı bir ölçüm sunacaktır.
- CFM ETH-CC mesajlarının sıklığına dikkat edilmelidir.
- Ethernet data plane loopback kullanışlı bir özellikdir.
- Y.1731 ölçümleri için LM veya SLM hangisi kullanılır ise kullanılsın, bir zaman aralığı içerisinde probelar gönderilir. Dolayısı ile kullanıcı datası üzerinde frame-loss olduğu anda uyarı almak mümkün değildir (AIS durumu hariç). Fakat oldukça kısa sürelerde raporlama alınabilir.
Şu an için networklerin uç kısımları ethernet, core ise MPLS tabanlıdır. MPLS mümkün olduğunca uca yayılmak istenmektedir.
CFM Domain’leri : Her bir yönetimsel bölge farklı domainlere ayrılabilir. İstanbul bir bölge, istanbulun alt bölgeleri ayrı bir bölge gibi. MPLS altındaki her ethernet domain’i, ayrı bir CFM domain olarak’da konumlandırılabilir.
CFM MD seviyeleri :
0 : Tek bir link. İki backbone cihazı arasındaki linkler level 0 olarak konumlandırılabilir.
7 : Müşteri kullanımı için.
6 : Test amaçlı UNI-C’de (CPE’de PE’ye bağlı port’da down MEP olarak) kullanılabilir. Veya Managed CPE’de, CPE’nin müşteri portunda veya bridge-fonk üzerinde up MEP olarak konfigure edilebilir.
5 : PE’de servis uç noktaları için. İnternet router’a, BRAS’a veya NNI switch’e doğru birer tane.
CPE – PE arasında :
1 – E-LMI, MPLS veya CFM hatalarını, durumunu CPE bildirmek için.
2 – Ethernet OAM
3 – CPE’de data plane loopback.
4 – PE’de verilmeyen servisler için filtreleme : CFM mesajları vb filtreleme
Ethernet CFM, Y.1731, Performance Testleri
Linkler :
http://www.fujitsu.com/downloads/TEL/fnc/whitepapers/CarrierEthernetEssentials.pdf
https://www.ciscolive.com/online/connect/sessionDetail.ww?SESSION_ID=78616&backBtn=true
https://www.nanog.org/meetings/nanog56/presentations/Tuesday/tues.panel.higgins.2.pdf