Студио Проекти в НБУ

 Абстракт

Студио проектите са нов елемент от образованието на студентите от инженерните специалности в Нов Български Университет. Основната им идея е студентите да се научат да работят в екип по реални проекти, поставени от външни заинтересовани лица, от водещи компании в България и под менторството на преподавателите от университета.

Ключови думи

Студио проект, НБУ, студенти, работа в екип, сътрудничество между бизнес и университет

Увод

Като част от усилията ни да променим облика на инженерните специалности в НБУ, преподавани в департаменти Информатика и Телекомуникации, въведохме курс по Архитектурни на Софтуерни системи към департамент Информатика, курс по PSP/TSP, положихме началото на бакалавърска програма “Мрежово Инженерство” към департамент Телекомуникации, реализирахме летен курс по “Estimating Software Development Projects” и семинари на тема “Combinatorial testing” и Buffered Moscow rules с д-р Едуардо Миранда от Carnegie Mellon University.

Във връзка с тези усилия представяме и следващата стъпка в тази посока – Студио проект в НБУ. Студио проектите са  възникнали в  Carnegie Mellon University като част от образователна програма MSE (Master of Software Engineering). Възниква въпроса що е то студио проект и каква е предисторията им.

Дефиниция

StudioProjects

The Studio Project, a capstone project that spans the duration of the program, allows for students to plan and implement a significant software project for an external client. Inspired by the design projects in architecture programs, students work as members of a team under the guidance of faculty advisors (mentors), analyzing a problem, planning the software development effort, executing a solution, and evaluating their work.

Преведено на нашенски това е проект, протичащ през цялата продължителност на учебната програма, в който студентите планират и разработват проект с не-малка сложност за външен клиент.

Както в Карнеги Мелън така и в НБУ студио проектите са вдъхновени от задачите давани към курсовете по Архитектури на Софтуерни системи и са базирани на множество принципи като: работа в екип под ръководството на ментор от университета, анализ на проблем, извличане на изисквания, планиране и остойностяване на процеса на разработка, разработка и оценка на направеното.

Студио проектите са описани от множество автори като James Tomayko, David Garlan, David Root и Mell Rosso-Llopart в множество статии като [1], [2] и [3]. На база на литературните източници и опита от “живия живот” на автора поставихме студио проектите в НБУ в следната рамка от принципи и правила.

Основни принципи

  •  Проектите се възлагат на екипи от студенти, внимателно подбрани на база на техните предишни умения, настоящи амбиции и текущи профили.
  • Всяка една от частните или публични организации, които желаят да работят с университета и студентите на НБУ, могат да зададат един или повече от един „studio” проект.
  • Университетът осигурява (доколкото му е възможно) материално всеки един от екипите. Например всеки един екип може да използва измервателното оборудване (осцилоскопи, спектрални анализатори, генератори на сигнали), ресурсите на библиотеката и сървъри и виртуални машини, мрежови устройства маршрутизатори, комутатори и др.
  • Компанията задала темата осигурява допълнителното оборудване, необходимо за реализацията на конкретния проект. Например това може да включва опитни постановки, с които университета не разполага, акаунти за даден тип облачна инфраструктура, компоненти за изграждането на вградени системи и д.р.
  • Във всеки един от екипите участва представител на бизнес организацията, която е възложила проекта и един или двама ментори от самия университет, които да подпомагат студентите по време на реализацията му.
  • За да могат студентите практически да изпълнят задачите си те трябва да получат от университета, а и от компаниите, възложили им проекта познания как да го направят.
  • Всеки един семестър студентите са длъжни да направят две презентации по проекта си:
    • В средата на семестъра (дефинирани цели и прогрес по проекта)
    • В края на семестъра (реализирани цели, отклонения от първоначално поставените цели, прогрес по проекта)
  • Авторските права на конкретната разработка са на самите студенти, освен ако изрично не е упоменато друго (т.е компанията спонсор на проекта, може да наложи съответни ограничения под формата на предварително подписан NDA-Non Disclosure Agreement)

Основно изискване

    • Студио проектите изискват време както от страна на студентите така и от страна на менторите и от представителите на бизнеса
    • Очакванията ни са, че за успешната реализация на един студио проект ще бъдат необходими от:
      • 6-8 ч на седмица от страна на всеки студент, участник по проекта
      • 2 ч на седмица от страна на ментора
      • 2 ч на седмица от страна на компанията

Ползи за студентите

  • Студентите се научават, че работата в екип не имагинерен израз в обявите за работа. Напротив получават задача, която могат да реализират само и единствено като работят в екип.
  • Студентите добиват реален опит в работата с реален клиент
  • Студентите се научават как да извличат и комуникират изисквания, срокове и ограничения с реален клиент
  • Студентите се научават как да презентират собствения си труд
  • Студентите научават конкретен бизнес домейн и технологичната еко-система,  в която той “вирее”
  • Участието на студентите в проектите им носи дивиденти като кредити свързани със стаж по специалността, кредити от извънаудиторни упражнения по различни предмети, а направената от тях разработка може да бъде използвана за дипломна работа
  • Проекта си е ред в CVто (кат има много неща вътре не е важен, ама като няма и трябва да се търси работа си е нещо)

Студио проекти vs директно започване на работа или постъпване на стаж

Възниква въпроса “Защо да изберем участието в студио проект вместо да се хванем на работа някъде или да започнем стаж?”. Отговорът е, че зависи какво целите. Ако искате да се хванете на работа и имате нужда от пари за да се прехранвате най-добре се хванете на работа. Ако търсите стаж най-добре се запишете в някой проект като питате предварително ментора си дали компанията, която го е обявила случайно не търси и стажанти през летния период. Вероятността да си намерите стаж в случая е клони около 100 %. Разликата е, че вместо стаж в който само ще висите и ще лапате мухи ще попаднете на стаж, в който вече познавате компанията, знаете какво ще правите, знаете кой да питате как да го направите.  С две думи стажа ви ще премине доста по-ползотворно, отколкото, ако просто се изтърсите някъде…

Важно е да се уточни какво е предимството на участието в студио проект и стаж пред директното започване на работа на пълен работен ден. Принципно компаниите са създадени да оперират, т.е да печелят пари. Когато започнете работа няма да сте особено квалифициран, ще започнете от най-ниското ниво и ще бъдете поставен в среда на доста ограничения. Вие ще искате да се развивате и да учите нови и интересни неща, но реално ще се случва обратното ще научите нещо конкретно, което ще носи пари на вашата компания и няма да имате време почти за нищо друго. Постепенно ще решите, че тази компания е “гадна” и ви ограничава. Ще си смените работата и ще идете при по-добра компания. Там ще се случи същото. Е ще научите още нещо, но пак ще бъдете поставен в доста ограничена среда. Постепенно ще свикнете, ще поостареете, ще дойдат и децата :) … и накрая никога няма да ви остане време да направите нещо интересно като студио проект….

Ползи за компаниите

Участието на дадена компания в студио проекти й дава възможност да планират и подготви от доста по издалеч така наречения процес по подбор на персонала. Всички знаем, че процеса по подбор отнема време и като цяло е доста “скъп”. Скъп е поради факта, че цифрата на добрите свободни ИТ хора, които мигом да наемем клони към минус безкрайност. Тези които са свободни обикновено не са особено “добри”, а пък тези дето са добри не са свободни. Химера е и факта, че има много свободни завършващи студенти, които знаят много и са жадни за работа. Първо тия които завършват вече работят, а тия които пък знаят задоволително много далеч не са много. Та да се върнем на процеса по подбор на персонал и внедряване на нов човек в дадена фирма. Които се е занимавал с това знае, че дори и да изберем нови хора, на тях им трябва време да станат ефективни. Това време си е чиста загуба на пари за компанията. Парите са свързани с разходи за заплати на новия човек, разходи за заплати на другите хора дето вместо да работят трябва ударно да го учат и като цяло наемането на нов човек си е един хазарт, при който далеч не винаги работодателя е печеливш. Студио проектите променят коефициентите в подобен тип  уравнение. Участниците от страна на компанията инвестират известно време (2ч на седмица, 8 ч на месец, 12 човеко-дни на година). На пръв поглед изглежда много, но като се има предвид, че това е време разхвърляно между всичко останало, далеч не тежи като това да губиш по-половин ден за няколко месеца в разяснения и обучение на нов човек. Освен това времето е отделено в нещо приятно, което така или иначе е интересно на ментора. В процеса на реализация на студио проекта ментора и компанията се запознават със студентите и имат достатъчно време да преценят техните умения, да доразвият тези които ще са им необходими за вбъдеще и да подготвят почвата, така че като студента завърши мигом да отиде на работа при тях, вместо някъде другаде.

Другият съществен плюс за всяка компания е самата разработка, която студентите, под ръководството на техните ментори развиват. Самите компании са бизнес организации, направени и да оперират, а не да иновират. Доказано е, че един от добрите начини да бъдат разработвани нови прототипи е именно в формата на малки откъснати от останалата част на компанията групи, които работейки в относителна изолация, успяват да постигнат доста повече от големи развойни екипи, които разработват в среди с много съображения и ограничения. Студио проектите подкрепят първия начин на работа и дават осовата за развитието на подобни иновации.

Партньори

До момента НБУ е подписало рамково споразумение с няколко водещи IT компании  като: Sap Labs Bulgaria, Microsoft Bulgaria, Test Solutions Ltd и др. За момента Sap Labs води с едни гърди на останалите компании като с тях вече сме дефинирали следните теми на проекти.

Cloud & SDN

Облаците и Софтуерно-дефинираните мрежи са две преливащи една в друга технологии от значение както за САП Лабс така и за НБУ.Целта на този проект е да бъде изградена IAAS&PAAS облачна инфраструктура върху SDN базирана мрежа с технологии като:

OpenStack   OpenDayLight  CloudFoundry

Automatic traffic optimization

trafficCompression

 

Cloud & BIG data изискват и “BIG” network. Понякога голямата мрежа просто липсва.
В този проект ще студентите ще трябва да разработят решение за само-оптимизация на компресията трафик в контекста на предоставяне на бизнес услуги на отдалечени потребители от платформата SAP Hana Cloud.

Internet of Things

InternetOfThings

Под общото наименование Internet of Things са обединени няколко решения свързани с теми като:

Smart Home

smartHome

Smart Mall

smartMall

Smart People

За “smart people” ще си позволя да напиша малко повече. Идеята идва от проекта за “Измерване на Електромагнитното поле” реализиран от НБУ и финансиран от Фонд научни изследвания. В процеса на работа по този проект стана ясно, че системите  за измерване на ЕМП се състоят от стационарни станции разположени на покриви. Реално те мерят сигнал, но трудно могат да ми кажат като потребител на какви радио-магнитни лъчения съм изложен на работното ми място, в трамвая, в къщи или в личния ми автомобил. Идеята на този проект е да бъде изработена система за измерването на подобни външни влияния върху нас, там където сме.

Записване

За момента всеки един студент, желаещ да участва в някои от проектите може да се запише на следния като попълни следната форма  http://goo.gl/forms/zyqcUz2Lrh.

Източници

  1. James Tomayko. Teaching Software Development in a Studio Environment, Association for Computing Machinery, ACM 0-89791-377-9/91/0002-03000, September, 1991.
  2. Garlan, David; Gluch, P. David; Tomayko, James E.: Agents of Change: Educating Software Engineering Leaders of Tomorrow, page 59-65. IEEE Software, November 1997.
  3. Root, D.; Rosso-Llopart, M.; Taran, G., Proposal Based Studio Projects: How to Avoid Producing “Cookie Cutter” Software Engineers, Software Engineering Education and Training, 2008. CSEET ’08. IEEE 21st Conference on , vol., no., pp.145-151, 14–17 April 2008
  4. Damasceno A., MSE studio project: The viewpoint of a UC student, .1109/CSEET.2011.5876133 Conference: Software Engineering Education and Training (CSEE&T), 2011 24th IEEE-CS Conference
  5. Милованов Н., Велев Ст., Студио проекти НБУ-САП ЛАБС България, Семинар по повод 20годишнината на деп. Телекомуникации, НБУ, 2014
Posted in Architectures for Software Systems, IT sector in Bulgaria | Tagged , , , , , , | Leave a comment

DDOS, RTBH and Self-Protection

A month ago ESI center asked me for a kind of cool 1 day  security oriented training course that has to bridge the gap between networking and software and to be different from everything else on the market.

So ready, set and done :)

DDOS, RTBH and self-protection will be a devOps oriented training in focused on application level DDOS attack mitigation. In the course  I will show how we can combine network traffic blackholling techniques with application based self protection.

The Official Dilbert Website featuring Scott Adams Dilbert strips, animations and more

The participants will learn how to use  source and destination based Remotely Triggered Blackholling  and how to embed it in their web applications.

As devOps tooling we will use maven, tomcat a development Environment as Intelij Idea or Eclipse, groovy and more precisely expect4groovy and we will produce a servlet filter able to detect the DDOS attack and pull  RTBH triggers.

So if you don’t want an army of mole  people from another dimension to storm through  your firewall and to suffer as Dilbert come to that one. More details on the portal of ESI.

Posted in Architectures for Software Systems, IT sector in Bulgaria | Tagged , , | 2 Comments

ICT Summer School@NBU Poster and Logo

Thanks to Martin Ormanliev from WT_ Design the ICT summer school have a brand new logo and our first official course got a poster :)

ICT summer school

ICT Summer School

Posted in Uncategorized | Tagged , , , , | Leave a comment

Dealing with IPv6 and Cisco IOU (IOS on Unix)

Recently I had the following issue with getting working IPv6 on Cisco IOU.

R1#sh ipv6 int e0/0
Ethernet0/0 is up, line protocol is up
IPv6 is stalled, link-local address is FE80::C00:FF:FE00:6500 [DUP]
No Virtual link-local address(es):
Global unicast address(es):
2001:470:1F0B:ABD::10, subnet is 2001:470:1F0B:ABD::/96 [TEN]
Joined group address(es):
FF02::1
FF02::2
MTU is 1500 bytes
ICMP error messages limited to one every 100 milliseconds
ICMP redirects are enabled
ICMP unreachables are sent
ND DAD is disabled
ND reachable time is 30000 milliseconds (using 35029)
ND advertised reachable time is 0 (unspecified)
ND advertised retransmit interval is 0 (unspecified)
ND router advertisements are sent every 200 seconds
ND router advertisements live for 1800 seconds
ND advertised default router preference is Medium
Hosts use stateless autoconfig for addresses.

The output of  ‘debug ipv6 nd’ was:

*Apr 18 04:32:04.405: ICMPv6-ND: Request to send RA for FE80::C00:FF:FE00:6500
*Apr 18 04:32:04.405: ICMPv6-ND: Sending RA from FE80::C00:FF:FE00:6500 to FF02::1 on Ethernet0/0
*Apr 18 04:32:04.405: ICMPv6-ND:     MTU = 1500
*Apr 18 04:32:04.405: ICMPv6-ND:     prefix = 2001:470:1F0B:ABD::/96 onlink autoconfig
*Apr 18 04:32:04.405: ICMPv6-ND:          2592000/604800 (valid/preferred)
*Apr 18 04:32:04.417: ICMPv6-ND: ND output feature SEND executed on 3 – rc=0
*Apr 18 04:32:04.445: ICMPv6-ND: ND input feature SEND executed on 3 – rc=0
*Apr 18 04:32:04.445: ICMPv6-ND: Received RA from FE80::C00:FF:FE00:6500 on Ethernet0/0v
*Apr 18 04:32:10.857: ICMPv6-ND: REACH -> STALE: 2001:470:1F0B:ABD::1

The solution:

1. Configure another link-local address

2. Disable duplicate address detection

interface Ethernet0/0
ip address 10.17.1.13 255.255.255.0
 ipv6 address FE80::69 link-local
ipv6 address 2001:470:1F0B:ABD::10/96
ipv6 enable
 ipv6 nd dad attempts 0

Finally a “Great Success” has been achieved :)

Posted in IPv4 to IPv6 network transformation | Tagged , , | 2 Comments

Курсове към програма Мрежово инженерство, деп. Телекомуникации на НБУ

Въведение

Представям кратък обзор на курсовете, които съм предложил към програма мрежово инженерство на деп.  Телекомуникации.  Програмата ще започне от следващата учебна година (2014/2015). Основната ѝ цел е да даде добри изходните перспективи за намиране на работа в България на завършилите я студенти. Моята лична цел е да предложа група от курсове, които да са изключително практически ориентирани, с минимално количество теория, които да изградят хора, способни да проектират и администрират различни по големина мрежови инфраструктури, а също и да работят в софтуерни компании, предлагащи продукти силно свързани с работата в мрежова среда.

Работодателите, които биха имали полза от подобни кадри са компании като Мобилните оператори, доставчициците на Интернет и виртуални частни мрежи, съпорт центрове, компании предлгащи облачни услуги, центрове за данни,  производители на софтуер за управление на мрежи или на такъв силно зависим от мрежовата среда, системни интегратори и почти всяка останала компания имащо корпоративна мрежа като банки, държавни институции, големи вериги магазини и други. За тези които обичат чуждите модни понятия целта е да направим devOps инженери със задълбочени познания по мрежови технологии абе с една дума netDevOps нинджи.

Моля всички, имащи потенциален интерес било работодатели, приятели или бъдещи и бивши студенти да ми изпратят своите коментари. С радост ще се опитам да  ги отрязя с цел да направим програмата максимално полезна на всички заинтересовани от нея.

Видео представяне на програмата

Увод в мрежовото инженерство

Курсът ще запознае с ежедневието на мрежовия инженер и ще им даде основата за последващите курсове от програма мрежово инженерство.
Студентите завършили курса :

  • ще умеят да боравят със linux/unix мрежови среди
  • ще знаят що е то “one-liner”
  • ще умеят да конфигурират мрежовите стекове на различни видове операционни системи
  • ще бъдат запознати с linux базирания рутер quagga.
  • ще конфигурират статична маршрутизация, RIP, OSPF на linux базирани рутери

Ключови думи:
Introduction to network engineering, linux, openwrt, quagga, one-liners, tcp/ip OS protocol stacks

Скриптове за автоматизация и управление на мрежи

Курсът ще запозне студентите с различните скриптови езици за комуникация с мрежово оборудване.
Студентите завършили курса :

  • ще умеят да пишат скриптове за автоматизация нa CLI на expect, perl и groovy;
  • ще умеят да пишат скриптове за автоматизация нa SNMP на, perl и groovy и xslt;
  • ще знаят що е то Web услуга;
  • ще умеят да боравят с конфигурации като документи, ще знаят да работят с конфигурациите на устройствата чрез XML и JSON формати за данни;
  • ще умеят да управляват мрежи чрез SDN контролери;
  • ще умеят да моделират мрежи и системи в различни модели от данни.

Ключови думи:
Network element interfaces, expect, expect4groovy, perl, xml, xslt, json, SNMP, Puppet, Chef, early SDN

Методи и технологии за разкриване и одит на мрежови инфраструктури

Курсът ще запознае студентите с подходите за разкриване и одит на мрежови инфраструктури.
Студентите завършили курса :

  • ще умеят да боравят със средства за разкриване на мрежи като netTransformer;
  • ще бъдат запознати със Kali linux и средствата за проникване и одит на мрежи и крайни устройства, които Kali предлага;
  • ще бъдат способни да напишат приложения, способни да разкриват мрежови топологии и крайни устройства.

Ключови думи:
netTransformer, network discovery, Kali, offensive security, penetration testing

SDN – Софтуерно дефинирани мрежи

Курсът ще запознае студентите с новопоявяващите се технологии, протоколи и стандарти на софтуерно дефинираните, програмируеми мрежи.
Студентите завършили курса :

  • ще умеят да боравят с комутатори, поддържащи Openflow;
  • SDN контролери като Floodlight и OpenDayLight;
  • ще могат да напишат приложения, способни да взаимодействат програмно с мрежата.

Ключови думи
SDN, Openflow, i2rs, network programmability, OpendayLight project, Floodlight

MPLS Опорни мрежи

Курсът ще запознае студентите с MPLS опорните мрежи, с трафичното инженерство и с технологиите за предоставяне нa MPLS L2/L3 услуги.
Студентите завършили курса :

  • ще умеят да виртуализират мрежови топологии
  • ще умеят да конфигурират MPLS на различни видове мрежови устройства
  • ще умеят да конфигурират MPLS трафично инженерство на различни видове мрежови устройства
  • ще умеят да конфигурират различни видове BGP адресни семейства
  • ще умеят да конфигурират MPLS L2/L3 VPN услуги

Ключови думи
MPLS, L2 VPN, L3 VPN, ISIS&OSPF tuning, BGP address families, MPLS traffic engineering

IPv6

Курсът ще запознае студентите с IPv6, технологиите за преход от IPv4 към IPv6 и ще ги научи да създават стратегии за преход между спрямо даден контекст и интерес на конкретни заинтересовани лица
Студентите завършили курса :

  • ще умеят да конфигурират IPv6 адреси и маршрути на различни мрежови устройства;
  • ще умеят да конфигурират IPv6 механизми за преход като 6to4 тунели, двоен IP стек, nat64;
  • ще умеят да конфигурират IPv6 DNS записи в BIND;
  • ще умеят да формализират съсъстоянието на мрежата, и да създават стратегии за преход, които да са свързани с конкретен контекст и интерес.

Ключови думи:
IPv6, IPv4 to IPv6 transition mechanisms, dual stack, nat64, 6to4, context aware state to state network transformation

Posted in IPv4 to IPv6 network transformation, MPLS Core Networks, Network Architecture Evolution, NGN Backbone Networks | Tagged , , , , , | 12 Comments

An approach and a tool for IP network state-to-state transformation

Abstract— The article presents an approach and a tool for network state-to-state transformation. Each network has a state. The state could be formalized into an architectural graph data model that contains network nodes, edges and key metadata. The state-to-state transformation happens as a chain of evolution steps from the initial to the desired network state. Each step has technical and business constraints, an action and leads to a desired effect. The steps could be combined in strategies. The strategies could be formally evaluated through the algorithm for multi-criteria analysis based on the business constraints associated with the containing steps. The successor strategy is called an “evolution path” and is the one that will be used to evolve the network. The approach has been fulfilled through a software tool able to discover the network state, to upload it in a graph data model, to change it and to perform a rediscovery finally to visualize the differences between the two network states.

Keywords-component: Approach for IP network state-to-state transformation, IPv4 to IPv6

Download the full article from here.

Posted in IPv4 to IPv6 network transformation, Network Architecture Evolution, OSS/BSS | Tagged , , | Leave a comment

What will be the SDN impact on OSS?

Currently on top of the network each and every medium large organization has a whole stack of OSS systems covering different sections of the E-TOM model.

We got network planners, commercial and technical order management systems, service and resource inventories,  network assurance and monitoring platforms, complex provisioning and activation engines.

As a person making the living from that industry I wonder what will be the impact of SDN  on all that?

In my personal (I have to state twice personal) opinion  SDN will bridge the gap between the BSS and the network and many of those complex OSS systems will become redundant.

At the same time it is fair to say that the complexity never disappears and as stated in RFC 1923 it just shifts from one place to another.

In that sense one possible scenario is to shift from the OSS to the BSS and mostly to the SDN controllers and intelligent clients.

Another one is that SDN will fail to prove itself as a carrier grade solution (there are many reason this to happen) and some of the ideas behind it to move straight into the OSS world. In this case the OSS will become more complex.

Stating this I truly believe that most of the effort in direction Openflow controllers and the initial marketing push of the ONF made a lot of noise but actually failed to prove themselves as a carrier grade network solutions. At the same time there are IETF initiatives such as the i2rs, abno and pce that are again an SDN and that look much more reasonable.  This will be the second wave of SDN and this wave and in my opinion this wave is that will simply some of the current OSS and will change the industry.

What do you think?

 

Posted in Network Architecture Evolution, OSS/BSS | Leave a comment

Introduction to Cloud Computing – Agenda and Poster

Agenda

  • Basic terms and characteristics of cloud computing.
  • Visualization
  • Infrastructure as a Service (IaaS)
  • Platform as a Service (PaaS)
  • Software as a service (SaaS)
  • Public, private and hybrid clouds
  • Cloud applications development
  • Programming models, architectures and frameworks
  • Basic cloud services
  • Security in the Cloud

Poster

Cloud_Computing_poster

 

Posted in Architectures for Software Systems, Network Architecture Evolution | Tagged , , | Leave a comment

Introduction to Cloud Computing

In software engineering, and network engineering the cloud is a set of principles and methodologies for designing and developing infrastructure and services on top of it in a new {or maybe not so new} more efficient {or who knows might be not that efficient} way. Typically when I hear about cloud based technologies in my mind suddenly comes statements such as:

  • Efficient usage of server and network resources
  • Self adaptation and automation
  • Managing big data
  • Integration between resources and external Internet of Things style ecosystems

On 16.04.2012 from 18:00 till {we finish} in NBU building 1, 311, as part of “Architecture for Software Systems” NBU course we will have a guest lecture – “Introduction to Cloud Computing”. As a lecturers we will have Stoyan Velev  and Hristo Dobtchev from SAP Labs Bulgaria.

Let’s come and hear what do they will tell us about the cloud…

Nikolay Milovanov

Posted in Architectures for Software Systems, MPLS Core Networks, NGN Access Networks, NGN Backbone Networks | Tagged | Leave a comment

Segment routing what the hell is this?

Introduction

In the last couple of years the awareness that the network somehow become too complex is rising more and more. Somehow the “stupid network” described by David Isenberg’s [1] become complex again… So it is time to turn the wheel one more time and to try to reduce the network state that has to be maintained and to try to shift the complexity in yet another direction.

Let’s track the network evolution

Consider the fact that before the complexity has been shifted from the network to the terminals so as a result we got quite capable end hosts instead of a dull telephones.

The initial packet networks were designed to sustain to a nuclear blast and the major concern in designing their architecture was network survivability. Now the world of networking is moved by a bit different business concerns. Such are the ability to utilize fully each network link, client isolation on common network infrastructure, ability to resist on DDOS attacks, selective performance, selective high availability.

Each one of those is not that easy to be achieved on pure IP network infrastructure. Some of those are possible to be fulfilled in pure MPLS based infrastructure and almost any could be fulfilled in MPLS + MPLS based network infrastructure. However that comes with its cost and the cost is the ability to maintain more and more network state in more and more complex control plane. So here comes the question can’t we somehow reduce the complexity of the issue with maintaining so many control plane protocols.

The answer is that there is such – why not connect all the nodes in a network to a controller make them all speak a common protocol with it through an out of band channel and then just let’s play with the controller.

Software Defined Networking

Ready set and done -> You got the openflow and SDN (Software Defined Networking). The idea is not new it somehow looks similar to the one of the intelligent telephony network described by Isenberg. In that one the network is controlled by intelligent nodes through a common protocol – SS7 (Signaling System No7) and its extensions (TCAP, INAP, MAP and so on).

It is important to understand that the SDN comes with its impact to the network quality attributes. Obviously it will reduce the network state maintained by each of the network nodes and will reduce the cost for achieving qualities such as network utilization, isolation, DDOS resistance, QOS and selective high availability on a per flow basis. However this will come on a certain cost. The cost will be inhibiting  network survivability. Obviously there will be controllers that will have centralized control on the network state. The complexity of the current network will be shifted towards those nodes and it won’t be easy to make them high available, work with the required performance and able to resist on different kinds of network based attacks.

Most of us have sensed what happens with the telephony network on New Year or when there is a problem with the main telephony switch. Same will happen with the packet network.

Anyway what is Segment Routing

SR (Segment Routing) is currently (30.03.2013) described in an IETF draft. The draft is driven by CISCO systems and is supported by leading Telecom Companies. The nutshell is expressed in the draft itself.

Segment Routing (SR) enables any node to select any path (explicit or derived from IGPs SPT computations) for each of its traffic classes.The path does not depend on a hop-by-hop signaling technique (neither LDP nor RSVP). It only depends on a set of “segments” that are advertised by the IS-IS routing protocol. These segments act as topological sub-paths that can be combined together to form the desired path.

There are two forms of segments: node and adjacency. A node segment represents a path to a node. An adjacency segment represents a specific adjacency to a node. A node segment is typically a multi-hop path while an adjacency segment is a one-hop path. SR’s control-plane can be applied to IPv6 and MPLS dataplanes.

Segment Routing control-plane can be applied to the MPLS dataplane: a node segment to node N is instantiated in the MPLS dataplane as an LSP along the shortest-path (SPT) to the node. An adjacency segment is instantiated in the MPLS dataplane as a cross-connect entry pointing to a specific egress datalink.

As per its designers it clings to the network qualities by offering Scale and Simplicity.

Simplicity
– less protocols to operate
– less protocol interactions to troubleshoot
– avoid directed LDP sessions between core routers – deliver automated FRR for any topology

Scale
– avoid millions of labels in LDP database
– avoid millions of TE LSP’s in the network
– avoid millions of tunnels to configure

Segment Routing and SDN

The draft describes how SR brings some of the SDN qualities without the introduction of a centralized control point. However
at the same time both technologies could co-exist.

Some of the SDN requirements are:

  • Guarantees of Tight SLA’s (FRR and bandwidth admission control).
  • Efficient use of the network resources.
  • Very high scaling to support application-based transactions.

Segment Routing (SR) is a compelling architecture to support SDN for the following reasons.

  • SR supports a simple but efficient capacity planning process based on centralized optimization.
  • SR optimizes network resources by providing a very simple support for ECMP-based shortest-path flows.
  • SR provides for much better scaling than alternative solution: several orders of scaling gains have been illustrated in the simplicity and Capacity Planning sections.
  • SR provides for guaranteed-FRR for any topology.
  • SR provides for ultimate virtualization as the network does not contain any application state.The state is in the packet. It is encoded as a list of segments.
  • SR provides for very frequent transaction-based application as the network does not hold any state for the SR-encoded flows.

More for Segment routing

[1] Isenberg D., Rise of the Stupid Network http://www.hyperorg.com/misc/stupidnet.html

Posted in MPLS Core Networks, Network Architecture Evolution, NGN Backbone Networks | Tagged , , | 3 Comments