Fu he Imp o emen s o an exis ing IP 6 Ne wo k
Mobili y Tes -bed
JosepM
a
Tomàs Sanahuja
Munich (Ge many)
Sep embe 2010 - Ma ch 2011
Tu o : Jaime M. Delgado Me cé
Ba celona School o In o ma ics - FIB
Uni e si a Poli ècnica de Ca alunya - UPC
T iaGnosys GmbH
Supe iso s: Àngels Via Es em and E iza Had Fazli
Ag aïmen s
A o s aquells que al lla g d'aques s úl ims anys han e possible que seguís enda an en els
momen s més di ícils i de necessi a , mol es g ácies a o s osal es.
A u Joan que du an 3 anys has es a el meu cap en el depa amen del TSC, pe o a la
exibili a o o gada al lla g d'aques s anys i l'aju p es a quan l'he hagu de menes e . Han
es a uns es anys els quals en gua da é mol bons eco ds, g àcies pe o .
G àcies ambé An onio pe aques s es anys al depa amen del TSC. Han es a es anys
dels que n'es ic mol con en de ha e pogu iu e i ap és. G àcies.
Vold ia ag aï a la Nú ia Cas ell. Al lla g de l'úl im pe íode de la ca e a 'he ingu com a
p o esso a de In eligéncia A icial i he pogu man ind e con e ses sob e el com enca a la me a
ca e a en un lla o s, alo a possibili a s pe a e un màs e , àmi s pe a beques a Japó i
nalmen la possibili a de eali za el p ojec e de nal de ca e a (PFC) a l'ex ange a Múnic,
Alemanya. Ha es a una mol bona expe iéncia de la qual semp e en man ind é un bon eco d i
de la qual semp e me'n sen i é p i ilegia de ha e -la iscu .
Ag aï a l'Ãngels i a l'E iza pe el seu aju i supo en la asca dins el p ojec e. També
ag aï les ecomanacions del meu u o Jaime Delgado en el edac a nal de la memò ia.
Finalmen ag aï a o a la me a amilia pe el supo dona al lla g d'aques s anys.
A la me a à ia Pepe a que no aig a iba mai a conèixe . Al meu a i Ra el Tomàs que en
pau descansi. Al meu a i Blai Sanahuja que ens a deixa a à un any, ell semp e a p ocu a
pe la me a educació i benes a , semp e, semp e en a eni cu a i ns els seus úl ims dies en
man ingué. Es ic segu que n'es a ies o gullós i n'es a ies co oi. En els úl ims dies abans que ens
deixèssis e aig di :
Es igues anquil pe què i a é enda an i me'n enso i é
A dia de a ui e puc di :
He comple , i con inua é i an enda an , po s es a -ne segu . Res és impossible si amb
es o ç i olun a un hi pe sis eix, a d o d'ho a semp e se'n acaba ob enin esul a 
I nalmen a les dues pe sones que ho han dona o pe a mi en aques a ida i que an de
sac ici han e , les dues pe sones pe a les quals el meu p esen i el meu u u ho són i ho han
es a semp e o pe a ells. A el meu pa e i a la me a ma e.
G àcies
Con en s
Lis o Figu es
Abb e ia ions ii
1 In oduc ion 1
1.1 Mo i a ion ....................................... 1
1.2 Goals .......................................... 3
1.3 Repo S uc u e.................................... 4
2 IP 6 O e iew 5
2.1 In oduc ion....................................... 5
2.2 Basic cha ac e is ics o IP 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 In oduc ion o Mobili y IP 6 p o ocol . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3.1 MobileIP 6p o ocol.............................. 8
3 Tes bed Cu en S a us 11
3.1 In oduc ion o NEWSKY es bed a chi ec u e . . . . . . . . . . . . . . . . . . . 11
3.1.1 NEWSKYbackg ound............................. 11
3.1.2 NEWSKY es bed a chi ec u e . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2 In oduc ion o SANDRA scena io . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2.1 SANDRAgoals................................. 12
3.2.2 SANDRA a chi ec u e and es -bed . . . . . . . . . . . . . . . . . . . . . 13
3.3 Aim o a e sing IP 6 ac o e a sa elli e IP 4 ne wo k . . . . . . . . . . . . 15
3.4 Rele an and non ele an ac ypes in SANDRA . . . . . . . . . . . . . . . . 15
i

4 Mobili y + IP 4 T a e sal 17
4.1 Conside ed P o ocols as a solu ion o SANDRA . . . . . . . . . . . . . . . . . . 17
4.1.1 M6Tp o ocol ................................. 17
4.1.2 DSMIP 6.................................... 19
4.1.3 NeXT ...................................... 20
4.2 P o ocolcompa ison .................................. 24
4.3 NeXTasop ionchosen ................................ 26
5 Tes bed Au oma ion 31
5.1 IP 6 Ne wo k Mobili y Tes bed A chi ec u e - Technical ea u es . . . . . . . . . 31
5.2 How he IP 6 Ne wo k Mobili y Tes -bed was swi ched on . . . . . . . . . . . . . 33
5.3 Conside ed op ions o he au oma ion . . . . . . . . . . . . . . . . . . . . . . . . 34
5.3.1 Use o C on + Bash sc ip s: . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.3.2 Use o /e c/ c.local + Bash sc ip s: . . . . . . . . . . . . . . . . . . . . . . 35
5.3.3 Use o /e c/ c.local + Ja a GUI + Bash sc ip s . . . . . . . . . . . . . . . 37
5.4 Final op ion: Use o /e c/ c.local + Ja a GUI + Bash sc ip s . . . . . . . . . . . 38
5.4.1 Die en ea u es o he Ja a GUI . . . . . . . . . . . . . . . . . . . . . . 38
5.4.2 Whe e a e he sc ip s loca ed and how a e hey execu ed ? . . . . . . . . 41
6 NeXT so wa e a chi ec u e/design 43
6.1 NeXT  s p o ocol e sion design . . . . . . . . . . . . . . . . . . . . . . . . . . 43
6.2 New NeXT equi emen s in SANDRA scena io . . . . . . . . . . . . . . . . . . . 44
6.3 Two die en NeXT design app oaches . . . . . . . . . . . . . . . . . . . . . . . 46
6.3.1 NeXTmul ip ocess .............................. 47
6.4 Th eadsIn oduc ion ................................. 53
6.4.1 Wha isaTh ead................................ 53
6.4.2 Whyusing h eads? .............................. 55
6.4.3 Wha is p h ead lib a y? . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
6.5 NeXT h eads...................................... 56
6.6 NeXTdesignchosen .................................. 60
7 Tes Cases 61
7.1 Case1.......................................... 61
7.2 Case2.......................................... 63
8 Conclusions and u u e Wo k 67
8.1 Conclusions....................................... 67
8.2 Fu u ewo k ...................................... 68
9 Re e ences and Bibliog aphy 69
Lis o Figu es
2.1 IP 6heade o ma ................................... 6
2.2 Mobili yp o ocol(1).................................. 8
2.3 Mobili yp o ocol(2).................................. 9
3.1 NEWSKY es -bed a chi ec u e . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2 SANDRA opology................................... 13
3.3 SANDRAa chi ec u e................................. 14
3.4 Ai acne wo k ................................... 15
3.5 Inma sa co e ageA ea ................................ 16
3.6 SANDRA ac .................................... 16
4.1 M6Tdeploymen .................................... 18
4.2 Ou e packe in MR and Ou e packe in HA . . . . . . . . . . . . . . . . . . . . 18
4.3 Packe in HA a e UDP decapsula ion is done by M6T en i y, he ou e IP 6
heade is heNEMOheade .............................. 18
4.4 Packe inCN ...................................... 19
4.5 NeXT .......................................... 20
4.6 NeXT heade s wi h IP 6 and mobili y legend . . . . . . . . . . . . . . . . . . . . 21
4.7 NeXT s eps om MN o NeXTSla e . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.8 NeXTs eps omCN oMN.............................. 23
1.3. Repo S uc u e
1.3 Repo S uc u e
A b ie explana ion o how he epo is s uc u ed will be gi en o an easy unde s anding o all
pe son ha in a close u u e wan o base i s wo k p ojec s in o his p ojec epo . The epo
 s alks abou he mo i a ion o he p ojec and men ions om an exis en gene al scope ha
ha e been wo ked wi h. Tasks ha ha e been done wi hin his p ojec a e also men ioned in
he Mo i a ion sec ion. A e wa ds
chap e 2
and
chap e 3
in oduces echnology backg ound
ha ha e been used. Chap e 2 and chap e 3 ha e no ela ion be ween hem, he  s one
alks abou IP 6 echnology which is used in he whole p ojec , a b ie desc ip ion o some o i s
ea u es a e explained, whe eas chap e 3 alks abou he exis ing and he upcoming a chi ec u e
in which he NeXT p o ocol is going o be deployed. This las chap e is e y impo an because
i in oduces he es -bed a chi ec u e and changes ha his es bed sue ed and was going o
sue , bu also i is impo an because some impo an decisions in e ms o he new NeXT
p o ocol design we e based aking he es -bed opology a chi ec u e in o accoun .
Bea in mind one hing,
chap e 2
and
chap e 3
desc ibes echnologies ha in his p ojec
ha e been used, howe e , o he echnologies will be in oduced in o he chap e s in o de o jus i y
hings and gi e a be e comp ehension o some aspec s. This p ojec is mainly abou NeXT
p o ocol and an IP 6 Mobili y es -bed, howe e , NeXT p o ocol is deployed in he es -bed and
bo h use o he echnologies o specic cases.
Chap e 4 in oduces he analysis p ocess o choosing he mos appealing p o ocol op ion
o be conside ed o he coming SANDRA es -bed scena io. Some aspec s o p o ocols a e
explained, he e a e also some compa isons be ween hem and some conclusions.
Chap e s 1 o 3 a e mo e heo e ical, whe eas chap e 4 in oduces he analysis p ocess in
he p ojec .
Chap e 5 is abou he es -bed Au oma ion, i is explained he p oblem ha he e was,
op ions conside ed and ac ions aken, some heo y abou some echnologies is also gi en. Chap e
6 is a chap e ha joins he design and implemen a ion p ocess in NeXT new e sion. In chap e
4 an in oduc ion o old NeXT  s e sion was gi en, in chap e 6 a mo e echnical explana ion
is gi en ocused on he implemen a ion aspec s. An in oduc ion o h eads is also gi en.
In chap e 7 some es cases a e explained. Chap e 8 wi h conclusions and u u e wo k and
nally chap e 9 in oduces e e ences and bibliog aphy.
4

Chap e 2
IP 6 O e iew
The In e ne Enginee ing Task Fo ce (IETF) has been de eloping In e ne P o ocol e sion 6
since he 1990s, his p o ocol is expec ed o eplace in a mid e m he cu en IP 4 due o he
sca ce o new a ailable add esses o assign, i s add ess space is nea ly o nish in a ew yea s.
Nowadays some companies and o ganiza ions a e ge ing in ol ed in he use o IP 6, an example
gi en is he Olympic games o China whe e public ne se ices used IP 6.
2.1 In oduc ion
IP 6 uses a 128-bi add ess, whe eas IP 4 uses only 32 bi s. I means he new IP 6 add ess
space suppo s
2128
(abou 3.4x
1038
) add esses. This expansion p o ides conside able exibili y
in alloca ing add esses and ou ing ac. As add ess size in IP 6 is 128 bi s i sol es he p oblem
o sca ci y add ess space in IP 4. I also adds he ea u e ha add esses can be au o congu ed,
mul icas ou ing has been imp o ed and new add ess ype has been in oduced, called Anycas
add ess explained in 2.1.
2.2 Basic cha ac e is ics o IP 6
2.2.0.1 Heade
The IP 6 heade has a xed leng h o 40 by es, 32 by es a e o add esses and 8 by es o gene al
heade in o ma ion. The heade o an IP 6 packe is specied in RFC
24601
. Figu e 2.1 shows
he IP 6 o ma .
5
2.2. Basic cha ac e is ics o IP 6
Figu e 2.1: IP 6 heade o ma
1.
Ve sion
(4 Bi s)
. In e ne P o ocol e sion numbe . In his case is 6.
2.
T ac Class
(1 By e)
. This eld eplaces he Type o Se ice eld in IP 4. Facili a es
he handling o eal- ime da a and any o he da a ha equi es special handling.
3.
Flow Label
(20 Bi s)
This eld dis inguishes packe s ha equi e he same ea men , in
o de o acili a e he handling o eal- ime ac: ou e s keep ack o ows so hey can
p ocess packe s belonging o he same ow mo e ecien ly because hey do no ha e o
ep ocess each packe 's heade .
4.
Payload Leng h
(2 By es)
. Leng h o he IP 6 payload coun ing he ex ension heade s.
5.
NeXT Heade
(1 By e)
. Iden ies he ype o heade immedia ely ollowing he IP 6
heade .
6.
Hop Limi
(1 By e)
. Exp esses a numbe o hops pe mi ed o each he des ina ion node.
E e y o wa ding node dec emen s he numbe by one.
7.
Sou ce Add ess
(16 by es)
. I con ains he add ess o he node ha gene a es he packe .
8.
Des ina ion Add ess
(16 by es)
. I con ains he add ess o he des ina ion node.
6
2. IP 6 O e iew
Many elds ha a e conside ed Op ions in IP 4 a e conside ed as Ex ension Heade s in
IP 6. Ex ension Heade s can be om ze o o mo e ex ension heade s in a packe bu hey a e
always be ween he IP 6 heade and he nex laye heade . Fo u he de ails consul IP 6 RFC
2460a
2.2.0.2 Ad essing
IP 6 has 3 ypes o add esses:
•
Unicas add ess
: unicas add ess uniquely iden ies a single in e ace o an IP 6 node
wi hin he scope o he unicas add ess ype. Depending o he p ex he add ess can be:

Link-local
: Is o use on a single link. I s p ex is
e80
and i can be used o au o
congu a ion mechanisms, o neighbo disco e y and o he s.

Si e-Local
: I s p ex is
ec0
. The add ess con ains subne in o ma ion. I can only
be ou ed wi hin he si e, he e o e ou e s can no ou e packe s ou side he si e. A
si e could be dened as a ne wo k a ea scope.

Global
: I uniquely iden i y a node all o e he wo ld and a e s uc u ed as Agg ega -
able Global Unicas
Add esses2
.
•
Mul icas
: I comp ises a g oup o add esses, his add ess can ha e die en scopes.
Packe s ha a e sen o a mul icas add ess, a e sen o all add esses ha akes pa in
he mul icas g oup.
•
Anycas
: I is assigned o mul iple in e aces (usually in mul iple nodes). I can no
be die en ia ed om a Global add ess, all nodes ha ha e an Anycas add ess ype
congu ed a e he only ones o iden i y i as Anycas ype add ess. When a packe is sen
o an Anycas add ess i is sen only o one o hem, usually he nea es one.
An IP 6 add ess consis s o h ee pa s: a global ou ing p ex, a subne ID, and an in e ace
ID. The add esses a e w i en as ollows:
IP 6 add ess/p ex leng h
Add esses a e di ided in o eigh 16-bi hexadecimal blocks, sepa a ed by colons, an example
is gi en:
2001:5c0:1505:6101:0000:0000:0000:3
IP 6 add esses can be simplied as ollows:
•
Leading ze os can be simplied by skipping hem.
•
Consecu i e ze os can be eplaced by a semicolon bu i can only appea only once in an
IP 6 add ess.
A e he ans o ma ion he IP 6 add ess looks like as ollows:
2001:5c0:1505:6101::3
7
2.3. In oduc ion o Mobili y IP 6 p o ocol
2.3 In oduc ion o Mobili y IP 6 p o ocol
E e y node has an IP 6 globally unique add ess and a link local add ess. These add esses a e
ela ed o he ou e in he ne wo k hey a e connec ed, hus when he node changes i s poin
o a achmen , IP 6 global unique add esses and link local add esses change.
When he add ess changes he exis en connec ions e mina e because hey can no be main-
ained. This happens because connec ions such as TCP a e cha ac e ized by he add ess and
po s o each one. I means ha he in o ma ion ela ed wi h he in e ace ( he one ha
changes i s poin o a achmen ) changes and he o he edge can no each i because i has he
old congu a ion add ess. A new connec ion wi h he new congu a ion mus be opened.
Mobile IP 6 o e comes his issue and allows main aining he exis ing connec ions he mobile
node ha mo es o a new ne wo k is communica ing wi h. Sec ion 2.3.1 explains b iey how
Mobile IP 6 p o ocol wo ks.
2.3.1 Mobile IP 6 p o ocol
When a node mo es o a new ne wo k i acqui es a new add ess, called Ca e-o Add ess (CoA)
om he new local ou e . A CoA is a empo a y add ess ha he mobile de ice acqui es when
i joins o a o eign ne wo k. I iden ies he cu en poin o a achmen o he in e ne and
makes i possible o connec om a die en loca ion wi hou changing i s pe manen add ess,
he Home Add ess (HoA). When he mobile de ice mo es o a new ne wo k i also main ains
HoA. When a node en e s o a new ne wo k he IP 6 Mobili y p o ocol wo ks as ollows:
Figu e 2.2: Mobili y p o ocol (1)
Be o e explaining how he IP 6 Mobili y p o ocol wo ks some e minology will be in oduced
o a be e comp ehension.
•
Ca e-o Add ess (CoA): I has been explained in he ini ial sec ion pa ag aph.
•
Home Add ess (HoA): Is he pe manen add ess ha iden ies he poin o a achmen o
he mobile node's home ne wo k.
8
2. IP 6 O e iew
•
Home Ne wo k: Ne wo k o whom a mobile node belongs, he one ha congu es i s
pe manen add ess ( he HoA).
•
Fo eign Ne wo k: Ne wo k in which a mobile node is ope a ing when away om i s home
ne wo k.
•
Home Agen : Node ha s o es in o ma ion abou mobile nodes whose pe manen home
add ess is in he home agen 's ne wo k.
•
Binding Upda e: Packe ha c ea es o enew an associa ion o he HoA wi h a CoA.
•
Binding Cache: Table main ained by a node. I con ains he cu en bindings (associa ions)
o mobile nodes.
•
Binding Upda e Acknowledgmen : Con ma ion o he BU packe .
•
Co esponden Node: Node ha communica es wi h a mobile node ha is ou o i s own
ne wo k.
The ollowing s eps co espond o gu e 2.2:
1. Add ess au o congu a ion, called Ca e-o Add esses.
2. The node sends a Binding Upda e (BU) o he HA, i binds he CoA o he HoA in he
HA which is in he Home ne wo k. I he node does no know he HA i uses HA disco e y
p ocess.
3. When he HA ecei es he BU, i s o es in he Binding Cache (BC) and sends back a
Binding Upda e Acknowledgmen .
A e ecei ing he BU Ack, he mobile node (mobile de ice) mus use he Re u n Rou abili y
P ocess in o de o send packe s o he Co esponden Node. The ollowing s eps a e ela ed o
his p ocess. Figu e 2.3 illus a es hem.
1. The node sends a Home es Ini (HoTI) message indi ec ly o he co esponden node,
unneling he message h ough he Home Agen .
Figu e 2.3: Mobili y p o ocol (2)
9

2.3. In oduc ion o Mobili y IP 6 p o ocol
2. The mobile node sends a Ca e-o Tes Ini (CoTI) message di ec ly o he co esponden
node.
3. The co esponden node sends a Home Tes (HoT) message in esponse o he HoTI mes-
sage.
4. The CN sends a Ca e-o Tes (CoT) message in esponse o he CoTI message.
A e doing his p ocess he nodes can communica e di ec ly using Rou ing Op imiza ion
(RO) ins ead o using HA. When a node is in a o eign ne wo k i sends packe s om i s ca e-o
add ess and includes he mobile node's Home Add ess in a Home Add ess op ion.
One ad an age o using RO is ha i ees he HA om ac, HA unnel in e aces ends
o become a bo leneck.
10
Chap e 3
Tes bed Cu en S a us
3.1 In oduc ion o NEWSKY es bed a chi ec u e
3.1.1 NEWSKY backg ound
The de elopmen o ecien ae onau ical communica ion sys ems is cu en ly a p edominan
opic in iew o he expec ed sa u a ion o ATM communica ions by 2020-2025 due o ai a -
c inc ease. In addi ion, he en isaged pa adigm shi in ATM as de eloped in SESAR and
he exis ing high ma ke demand o passenge communica ions a e he d i ing ac o s o he
mode niza ion o ae onau ical communica ions.
I is o eseen ha die en se ices, da a links and ne wo king solu ions will be deployed.
Die en se ices wi h highly di e se equi emen s shall coexis and pa ly o o ally sha e
he ae onau ical ne wo k in as uc u e. No single se ice on i s own jus ies he cos implica ion
o a new communica ion sys em. T ends o he die en ae onau ical se ices include:
•
Ai T ac Se ices (ATS): I will be p ima ily based on highly sa e y- ela ed da a com-
munica ion whe eas oice communica ion will be mos ly used as allback solu ion
•
Ai line Ope a ional Communica ions (AOC) da a ac: I will s ongly inc ease o e-
cien ai line ope a ions
•
Ai Passenge Communica ions (APC) sys ems: They o eseen o be u he de eloped o
mee passenge s expec a ions o on-boa d b oadband communica ion se ices.
Acco ding o bo h SESAR and he Fu u e Communica ions S udy join ly pe o med by
Eu ocon ol and FAA unde Ac ion Plan 17, hese se ices will use g ound-based, sa elli e-based,
ai c a - o-ai c a and ai po communica ion sys ems o ulll he equi emen s: a sa elli e link
(new s anda d de eloped wi hin ESA IRIS p og am), an ai po link (WiMAX), a high da a
a e ai -g ound link (L-DACS-1/2) and suppo o legacy da a links (e.g. VDL2). In addi ion,
u he da a links o APC a e expec ed o be deployed.
11
3.2. In oduc ion o SANDRA scena io
3.1.2 NEWSKY es bed a chi ec u e
Figu e 3.1 shows he old NEWSKY es -bed a chi ec u e. I has no go any IPsec Secu i y
Ga eways no IPsec unc ionali ies.
Figu e 3.1: NEWSKY es -bed a chi ec u e
A u he explana ion o his ype o opology is done in sec ion 3.2.2.
3.2 In oduc ion o SANDRA scena io
3.2.1 SANDRA goals
The SANDRA concep consis s o he in eg a ion o complex and dispa a e communica ion media
in o a lean and cohe en a chi ec u e ha :
•
P o ides and manages seamless se ice co e age ac oss all ai space domains and all ai c a
classes
•
Sus ains g ow h in he se ice ma ke and enables easy plug-in o u u e adio echnologies
h ough modula i y and congu abili y
•
Is upg adeable, easy econgu able and adio echnology independen
•
Is dis ibu ed and ins an ia ed in o consis en g ound-based and ai bo ne sub-ne wo ks
ensu ing ull in e ope abili y. SANDRA co e s om RF and a ionics componen s up o
he middlewa e laye o he on-boa d ne wo k, assembled and in eg a ed unde he mos
s ingen sa e y and secu i y equi emen s. Ul ima ely, SANDRA pu sues he a chi ec u al
in eg a ion o ae onau ical communica ion sys ems using:
- Well-p o en indus y s anda ds like IP, IEEE 802.16 (WiMAX), DVB-S2, Inma sa
Swi B oadBand
12
3. Tes bed Cu en S a us
- A se o common in e aces
- S anda d ne wo k p o ocols ha ing IP 6 as nal unica ion poin o enable a cos -
ecien global and eliable p o ision o dis ibu ed se ices ac oss all ai space domains
and o all ai c a classes.
3.2.2 SANDRA a chi ec u e and es -bed
Figu e 3.2 shows how SANDRA opology is in a labo a o y en i onmen . The uppe box on he
le is a lab en i onmen ha emula es a eal scena io. The mos igh box o he pic u e can be
conside ed as a black box, wha happens inside i is anspa en o us. I is he one ha p o ide
ne wo k access o he echnology se ices such as sa elli e links (INMARSAT). The mos le box
is he one ha co esponds o he ai plane and ha is also emula ed in a labo a o y en i onmen .
Keep in mind ha he cu en es bed a chi ec u e is no like he one o he pic u e, bu in a
close u u e i should be some hing alike.
Figu e 3.2: SANDRA opology
In gu e 3.2 a box labeled
IMR
can be iden ied. IMR is an en i y a ached o MR ha
manages in e ace and ac in o ma ion anspa en o MR. I s mainly ask is o ake con ol o
in e aces congu a ion. Fo ins ance, IMR de e mines ha in e ace
e h1
om MR is congu ed
o be used wi h AR_Ku, i also handles si ua ions whe e in e aces in MR go down and ha e o
be eassigned o ano he AR_ link.
13
4.1. Conside ed P o ocols as a solu ion o SANDRA

In his scena io he mobile node is loca ed in an IP 4/IP 6 ne wo k capable, howe e ,
i uses some applica ion ha equi es IP 4 ac.
•
Scena io 5: IP 6 and IP 4-enabled ne wo ks

In his scena io, he mobile node should p e e he use o an IP 6 ca e-o add ess o
ei he i s IP 6 o IP 4 home add ess.
4.1.3 NeXT
NeXT is a p o ocol c ea ed and owned by T iaGnoSys GmbH company in Munich, Ge many. The
main aim o NeXT p o ocol is allowing he ansmission o IP 6 packe s h ough IP 4 links (i.e.
Sa elli e). This is done by ansla ing IP 6 heade s o IP 4 and again o IP 6 a e a e sing
hese links.
I can also wo k he o he way ound, o a e se IP 6 ne wo ks wi h IP 4 packe s.
Figu e 4.5: NeXT
NeXT consis s o wo main en i ies,
•
NeXTMas e
•
NeXTSla e
20

4. Mobili y + IP 4 T a e sal
Bo h NeXTMas e and NeXTSla e consis o wo sub-en i ies
•
NeXTMas e = NeXT64Mas e and NeXT46Mas e
•
NeXTSla e = NeXT64Sla e and NeXT46Sla e
NeXT64 en i y ansla es IP 6 ac in o IP 4 ac and NeXT46 en i y ansla es IP 4
ac in o IP 6.
In gu e 4.6 he legend o he die en ypes o packe s used in gu es 4.7 and 4.8 a e
shown.
Figu e 4.6: NeXT heade s wi h IP 6 and mobili y legend
Figu e 4.7 shows in a eal wo ld scena io which a e he s eps ha NeXT does when MN
s a s alking o CN and MN is in a o eign ne wo k:
1. A node (MN) gene a es he he  s packe o a session, he des ina ion is CN ou side o
he cu en MN ne wo k, hus he packe is sen o MR
2. When MR ecei es he packe i applies NEMO p o ocol o he packe (adding an ex a
IP 6 ou e heade ). A e wa ds i looks o an en y in he ansla ion able(s uc u e ha
holds he in o ma ion equi ed o ansla e he packe om one IP e sion in o o he ), as
i is he  s packe o he session i does no nd any en y ma ching he packe . Then a
new en y is c ea ed and add esses and po s a e assigned.
3. When an en y o he new packe is c ea ed he packe is sen wi h he IP 6 add esses
and o iginal po s as shown in gu e 4.6.
4. The packe eaches NeXTSla e, i looks o an en y in he able, as i does no nd any
en y i eads he IP 6 add esses om he packe and also he po s, hen i c ea es a new
en y o he packe .
5. The packe is ansla ed and sen o he HA ( emembe ha he e is NEMO heade in he
packe ).
21
4.1. Conside ed P o ocols as a solu ion o SANDRA
6. The packe eaches he HA, due o in s ep 2 an ou e IP 6 Heade was included by NEMO
using as sou ce add ess he MR's HoA and as a des ina ion add ess he HA's HoA. When
he packe a i es o HA i decapsula es he packe ( emo es he NEMO ou e heade which
includes he Home Add esses p e iously men ioned) i eads he CoA o m he packe and
sea ches i wi hin i s Binding cache (BC), i i is ound in he BC hen is ou ed o he CN.
Figu e 4.7: NeXT s eps om MN o NeXTSla e
Figu e 4.8 show in a eal wo ld scena io which a e he s eps ha NeXT does when CN s a s
alking o MN and MN is in a o eign ne wo k:
1. CN sends IP 6 packe o MN
2. Packe goes o HA
3. HA consul s i s BC and i he des ina ion is ound adds NEMO ou e heade (i includes
sou ce and des ina ion HoAs)
4. HA o wa ds he packe o he des ina ion HoA(MR HoA)
5. NeXT64Sla e in AR ecei es he packe
22
4. Mobili y + IP 4 T a e sal
Figu e 4.8: NeXT s eps om CN o MN
7. NeXT64Sla e looks in he able i he e is any en y ha ma ch he packe , as i does
no nd any NeXT64Sla e sends a signaling packe o he NeXTMas e wi h he add esses
and po s in IP 6 and asking o NeXTMas e an alloca ion o a IP 4 add ess. NeXTSla e
knows he mas e add ess due o i is specied in a congu a ion le, howe e , he add ess
is also p o ided by he  s packe ha NeXTMas e sends o NeXTSla e o s a an
exchange o ac da a. Fo u he de ails abou his congu a ion please see gu e 4.10.
8. NeXTMas e assigns a IP 4 add ess and po s and c ea es a new en y in i s able s uc u e.
9. NeXTMas e sends a eques ack o NeXTSla e wi h he new in o ma ion.
10. When NeXTSla e ecei es he in o ma ion, i c ea es a new en y in he ansla ion able
and ansla es he heade . Bea in mind ha his packe ha is going o be sen does no
con ain any IP 6 add ess since IP 6 add ess ha e been p e iously s o ed in NeXTMas e
when he signaling eques packe was sen .
11. NeXTSla e sends he packe
12. NeXTMas e ecei e he packe and ansla es i
23
4.2. P o ocol compa ison
13. NEMO p o ocol emo es he ou e IP 6 NEMO heade , and o wa d o i s ecipien .
NeXT p o ocol uses libne l e _queue lib a y. Libne l e _queue is an use space lib a y
p o iding an API o packe s ha ha e been queued by he ke nel packe l e . I is pa o
a sys em ha dep eca es he old ip_queue /libipq mechanism. Libne l e _queue has been
p e iously known as libn ne link_queue. I allows ecei ing queued packe s om he ke nel
n ne link_queue subsys em and also issuing e dic s and/o einjec ing al e ed packe s o he
ke nel n ne link_queue subsys em.
NeXT s ands o an ecien way o using IP 4 links bandwid h. One kind o IP 4 link ha
nowadays is used is sa elli e links. I p o ides communica ion in as a eas whe e o he echnolo-
gies and mechanisms can no , o example in ansa lan ic ai planes igh s. Howe e , despi e
sa elli e links a e cu en ly hough as an appealing solu ion o in e communica e (specially in
he skyline) i has one ea u e, using a sa elli e link is expensi e in e ms o ime/ ac usage.
NeXT in oduces ac o e head sa ing by how i ansla es IP 6 packe s in o IP 4 o ma .
NeXT sa es space bandwid h on using he sa elli e link due o how i ansla es packe s
om IP 6 o IP 4. NeXT does sa e space by sending a  s all he IP 4 and IP 6 in o ma ion
equi ed o NeXTSla e o do a mapping be ween he wo IP e sions (IP 6 add ess wi h po s
85000 and 86000 co esponds o he IP 4 add ess 184.67.9.5). When he NeXT Sla e has a
mapping en y in i sel da a s uc u e he ollowing packe s om he ow only ca y IP 4 in o -
ma ion (IP 6 mobili y heade s also) due o IP 6 in o ma ion had been p e iously s o ed in he
NeXTMas e and NeXTSla e. I is no jus UDP encapsula ion, i is some hing mo e ecien
han his.
4.2 P o ocol compa ison
A lis o d awbacks and ad an ages will be gi en o wo o he h ee p o ocols in oduced. M6T
is no conside ed o he ollowing easons.
In he ea lie p ocess o analyzing i s ea u es I hough ha i was no wo h o conside i
anymo e because i was some hing alike o NeXT p o ocol and u he mo e i added a cons an
o e head in o he sa elli e link. Wha is conside ed as o e head is he ou e IP 4 and he UDP
heade s added o he o iginal packe .
A sa elli e link is some hing e y expensi e in e ms o ac usage, no mally whoe e uses a
sa elli e link will be no mally paying o an amoun o ac consume h ough he link. The e o e
adding always 28 by es o ex a heade s was no an appealing ma e , NeXT solu ion managed
e en be e and in an ecien way his issue.
This is why o ha eason M6T will no be conside ed in his compa ison and p os and
cons. DSMIP 6 and NeXT will be he only ones.
P os and Cons o DSMIP 6 p o ocol a e shown below.
Ad an ages :
•
Allow 4 CoA
24
4. Mobili y + IP 4 T a e sal
•
Allow 4 HoA
•
Is a S anda d
Disad an ages :
•
DSMIP 6 implemen a ion is buggy
•
Can' un Mul ipleCoA-pa ched implemen a ion + NEMO
•
NAT a e sal is no implemen ed
•
O e head wi h UDP addi ion
The DSMIP 6 implemen a ion ha exis s and has been conside ed in his analysis is he one
om
Nau ilu67
. One o he d awbacks says ha he Mul ipleCoA-pa ched implemen a ion and
NEMO pa ch can no wo k oge he . The e is no so much in o ma ion abou his d awback, i
is only men ioned in i s ocial websi e. The e o e i has been deduced ha Mul ipleCoA-pa ched
implemen a ion and NEMO pa ch can no wo k oge he due o how hey a e ins alled. Bo h
o hem a e pa ches o he Linux ke nel ha add and eplace lines om i , I can happen ha
he e can be and o e lapping o some ke nel lines, he e o e some unc ionali ies o hose pa ches
can no wo k p ope ly.
In he es -bed, one e y impo an ea u e was he use o mul iple add esses, i was a mus .
Mul iple-CoA had o be p esen in he es -bed. Mo eo e NEMO was also a ea u e o he
es bed ha was a mus , on he op o ha , hey we e bo h al eady ins alled in he es bed. Fo
ha eason i was an impo an d awback ha sub ac ed poin s in o conside a ion o DSMIP 6.
Apa om ha DSMIP 6 implemen a ion pe o mance was no qui e s able. I showed so
many oubles wi h hando e s pe o mance making he whole sys em uns able because a e a
se ie o epe i i e hando e s he DSMIP 6 so wa e c ashed. The e we e o he bugs such as some
congu a ion policies dened by DSMIP 6 ha we e no emo ed a e exi ing om i . Ha ing
a s able beha io was some hing sough and DSMIP 6 didn' seem o p o ide i .
Nowadays DSMIP 6 implemen a ion hasn' go some unc ionali ies, o example DSMIP 6
lacks o NAT a e sal implemen a ion. Howe e , no all abou DSMIP 6 is nega i e, i has
posi i e ea u es like he possibili y o using a CoA 4 add ess and he dynamism i in oduces
because i makes possible o ha e only one Mobile IP p o ocol deployed. DSMIP is being also
conside ed by companies such as Qualcomm whose Sma Mobili y eam is de eloping a solu ion
based on he Dual S ack Mobile IP (DSMIP).
P os and Cons o NeXT p o ocol a e shown below.
Ad an ages :
•
Reliabili y o i s unc ionali y
•
Sa elli e bandwid h pe o mance
Disad an ages :
•
I is no a S anda d
25

4.3. NeXT as op ion chosen
4.3 NeXT as op ion chosen
NeXT p o ocol has been nally he chosen op ion o i s deploymen in he SANDRA scena io.
I allows ha ing Mul iple-CoA and NEMO unning a he same ime. Fu he mo e i gua an ees
an ecien use o he sa elli e link bandwid h as i has been explained in sec ion 4.1.3.
Adop ing NeXT o he SANDRA p ojec has i s implica ions and a deep p ocess on analysis
has o be pe o med. NeXT has wo main en i ies, Nex Mas e and Nex Sla e. I was  s
implemen ed as a one- o-one channel, i means NeXTMas e en i y only communica es wi h
NeXTSla e en i ies, a one- o-one speech. Howe e wi hin SANDRA his change due o i s
a chi ec u e.
Figu e 4.9: SANDRA scena io wi h NeXT
Wha comes now is he whole analysis ha was made o de e mine how NeXT would look
like i i would ha e been used in SANDRA and which new equi emen s would appea as a esul
o his p ocess.
An explana ion o gu e 4.9 will be gi en nex . Figu e 4.9 shows he SANDRA opology
scena io using NeXT. In his case wha is on he igh side o T iaGnoSys ou e is an emula ion
o SANDRA scena io bu emula ed inside T iaGnoSys ne wo k. T iaGnoSys ou e ac s as an
AR 4 ha leads o an IP 4 ne wo k. Wi hin his IP 4 ne wo k he e a e some AR 6 ha
co espond each one o a specic Regional A ea IP 6 Ne wo k. A Regional A ea Ne wo k is
an IP 6 Ne wo k ha can be ela ed whe he o a geog aphic a ea o a ype o se ice. Le s
suppose ha he e a e wo mobile nodes ( wo mobile de ices) ha ha e paid o some sa elli e
da a bandwid h and also o a ce ain ime du a ion. Le s iden i y he wo men ioned mobile
nodes as de ice A (DA) and de ice B (DB). DB has paid o a be e and quicke access o he
ne wo k han DA. DB hen is supposed o ha e be e speed han DA. DA has paid o se ice
A and DB has paid o se ice B. When packe s om DA eaches MR, hey a e sen ia he link
ha is associa ed o he ype o se ice, se ice A in his case. Then packe s each T iaGnoSys
AR 4 and some polices a e consul ed o de e mine o which AR 6 he packe has o be sen .
Looking o gu e 4.9 he e is a Mobile Ne wo k a ached o a MR. In he Mobile Ne wo k
he e a e die en nodes ha use die en con ex s, by die en con ex s we mean he e a e
26
4. Mobili y + IP 4 T a e sal
Figu e 4.10: Flow packe
die en needs o using one specic esou ce o ano he (L-band, Ku-band, WiMax2,..) depending
on he equi emen s in ow ac ype. So in some how we depend o wha IMR ells us, on
which in o ma ion i p o ides allowing o congu e Policy Rules, NEMO, and NeXT Mas e in
MR.
•
NeXT Mas e needs o know he in e ace in o ma ion o es ablish a binding socke channel
wi h NeXT Sla e, i.e. NeXT Mas e needs (1) a local in e ace on he MR wi h an IP 4
add ess (IP 4 CoA) o he espec i e IP 4 access ne wo k (can be i ual I/F), and (2)
he IP 4 add ess o he espec i e NeXT sla e. This channel is used o exchange signaling
and da a.
•
Assuming his, i is supposed ha IMR (an en i y a ached o MR ha manages in e ace
and ac in o ma ion anspa en o MR) p o ides he in o ma ion equi ed. The ollow-
ing ow cha illus a e wha is exchanged since MR eques in o ma ion esou ce o he
IMR, and o when all is p ope ly congu ed.
Figu e 4.10 shows a owcha ha desc ibes he s eps aken o allow he MR ecei ing some
ou e ad e isemen s om a egional AR 6 which i has no any bound ye wi h. The s eps a e
he ollowing:
27
4.3. NeXT as op ion chosen
1. MR asks o in o ma ion (makes a esou ce eques Resou ce Req 1) o IMR
2. IMR issues acco ding esou ce eques o he espec i e access ne wo k (chosen by ei he
MR o he IMR)
3. AR 4 (g ound s a ion) eplies gi ing a CoA 4
•
CoA 4 can be public
•
CoA 4 can be p i a e (NAT equi ed in IMR o in access ne wo k)
4. Wi h alloca ion o an CoA 4, he IMR needs o decide which i ual in e ace is se -up
be ween IMR and MR (VLAN, ppp,...). CoA 4, VLANx, and AccessNe wo k in o ma ion
is sen wi hin he Ack o he MR.
5. MR ecei es he Ack om IMR
6. MR congu es a CoA 4 and i congu es a new in e ace. Now NeXTMas e (in MR) can
es ablish a channel communica ion wi h NeXTSla e (in Regional AR 6).
7. NeXTMas e sends a packe wi h in o ma ion o NeXTSla e using a s c IP 4 add ess ( he
CoA 4) and a des ina ion IP 4 add ess ( he NeXTSla e IP 4 add .).
8. NeXTSla e doesn' know abou NeXTMas e , bu Mas e does (i knows AccessNe wo k/G ound
S a ion, hus public add ess 4 o NeXTSla e is deduced (i is likely ha he e is a
NAT be o e he NeXTSla e ha mus be congu ed acco dingly o pass packe s om
he NeXTMas e o he p ope NeXTSla e)
9. MR link hasn' go a CoA 6 ye , i is p o ided by Rou e Ad e isemen s (Ra). Howe e
ou e ad e isemen 1 (Ra1) and ou e ad e isemen 2 (Ra2) can no each MR ill
NeXTSla e knows abou NeXTMas e .
10. Ra1 and Ra2 a e disca ded by he A 6 because i doesn' know wha o do wi h hem.
A e NeXTSla e knows abou Mas e ou e ad e isemen 3 (Ra3) is sen .
11. MR ecei es he Ra3 and congu es an CoA 6 (NEMO does his).
12. A e wa ds MR congu es IP 6 policing ules o ou e he espec i e ac o e he newly
se -up ( i ual) in e ace. The MR also need o ansmi he applicable e e se policy
ou ing ules o he HA.
Which NeXTSla e shall be used by he NeXTMas e depends on a-p io i assump ions w. . .
whe e he AR 6 is loca ed in he g ound ne wo k o a gi en access ne wo k, i.e. i should be
congu ed and dened by he use . Example: I he assump ion is ha he AR 6 o he Ku-band
access ne wo k lies in Region 1, hen i mus be congu ed in he NeXTMas e ha o all CoA 4
belonging o he Ku-band access ne wo k he NeXTSla e belonging o he AR 6 in Region 1 is
used. This ensu es:
(a) The CoA 6 add ess alloca ed o he espec i e MR in e aces a e belonging o he espec i e
AR 6, which ensu es ha also he e u n packe s (CN -> MNN) a e ou ed o e he co ec
AR 6
28
4. Mobili y + IP 4 T a e sal
(b) NeXT packe s a e sen om he NeXTMas e o he igh NeXTSla e.
Fu he , he e a se e al op ions ha could be conside ed o he case when an access ne wo k
and acco dingly he esou ces al eady alloca ed on i become una ailable, howe e , i is ou o
he scope o my p ojec conside ing hem.
Bu why NeXTSla e is said o be placed in AR 6s? The eason is he ollowing one. Apa
om AR 6s, he only easible candida e o hink o hos ing NeXTSla e is he HA. Howe e ,
placing NeXTSla e in HA means ha he e is no possible way a all o ou e he packe s h ough
a specic egion ne wo k a ea due o he lack o ou ing in o ma ion. Thus u ning in o an
impossible ask o gua an ee ha a packe a e ses a specic Region ne wo k. Tha is why by
using AR 6 i can be p o ided wi hin ou e ad e isemen s p exes add esses o congu e an
IP 6 CoA which sol es he ou ing p oblem.
29
5.3. Conside ed op ions o he au oma ion
in Line 1 had p e iously congu ed some beha io . I can be said a ma e o p e equisi es and
equi emen s.
A ypical /e c/ c.local s uc u e is he ollowing one om below:
Figu e 5.4: Rc.local le
The le s a s wi h a shebang line, he one ha says #!/bin/sh -e . In compu ing, a
shebang line is he cha ac e sequence consis ing o he cha ac e s numbe sign and exclama ion
poin (#!), when i occu s as he  s wo cha ac e s in he  s line o a ex le. In his case, he
p og am loade in Unix-like ope a ing sys ems pa ses he es o he  s line as an in e p e e
di ec i e and in okes he p og am specied a e he cha ac e sequence wi h any command line
op ions specied as pa ame e s.
A e he command lines he sc ip e mina es wi h he exi command wi h a 0, saying i
success ully exi s om he sc ip .
As i has been men ioned, es bed nodes ha e a ious congu a ion sc ip s, some o hem can
be specied in he /e c/ c.local le, bu he e a e o he s ha a e be e no o because depending
on which scena io i is in ended o pe o m a simula ion he e will be some congu a ion sc ip s
ha will be load and o he s ha won' . Besides, he e a e sc ip s ha needs inpu alues ha
dene o example packe delay, in e aces and o he pa ame e s.
Tha means he e is he need o human in e ac ion o in a nal ins ance congu e he es bed
o a scena io ha equi es an specic beha io .
I can be said ha he e a e mainly wo scena ios, each one wi h i s co esponden sc ip s
and congu a ion les. These wo scena ios a e:
•
Simula ing a sa elli e link using c command, adding delay o he packe s.
•
Using BGAN sa elli e link.
36

5. Tes bed Au oma ion
The s eps o be ollowed in o de o pe o m he au oma ion p ocess a e:
•
Some congu a ion les a e added o he /e c/ c.local
•
Once he node is ei he eboo ed o s a ed up he congu a ion les in /e c/ c.local a e
sequen ially launched.
•
The use execu es a bash sc ip om he command line
This las poin o he lis , 
execu ing a bash sc ip om he command line
 is he s ep in
which he e is human in e ac ion wi h he sys em in e ms o congu a ion ac ions. An example
o a scena io simula ion base case will be now in oduced.
Base case:
Gi en an scena io using Sa elli e emula ion link, sc ip s A, B, C and D a e dened in he
/e c/ c.local. All he es bed nodes a e eboo ed. Then a e wa ds launching a sc ip , i doesn'
ma e i i is whe he om local compu e o Humbold . This sc ip will make a se ies o
ques ion asking o specic beha io ma e s, such as, ¾Do you wan o apply packe l e ing¾`,
i he answe is a ma i e hen some pa ame e s o he packe l e ing a e sugges ed o he
sys em. A e wa ds he use is able o choose whe he accep he sugges ion o dene i s owns
pa ame e s. This se ies o ques ions es ablish a specic congu a ion o he whole es bed
beha io .
Once he use has answe ed all he ques ions, a lis o all he op ions p e iously chosen is
shown and he use is asked o con m i all he pa ame e s and op ions a e okay. In case o
selec ing No he use has he op ion o modi y he pa ame e s and op ions he wan s.
Un il his s ep he e has been no o de s o any o he es bed nodes, wha has been done is o
s o e he op ions chosen by he use in a iables. Tha means ha only a e he use con ma ion
emo e commands using ssh a e sen o he die en nodes o he es bed o success ully launch
he sc ip s ha de e mine a beha io .
5.3.3 Use o /e c/ c.local + Ja a GUI + Bash sc ip s
The hi d op ion conside ed o he es bed au oma ion is he implemen a ion o a Ja a G aphic
Use In e ace (GUI). This Ja a GUI checks he node's s a us unde eques and manages he
s a , eboo , and shu down o hem ei he one pe one o by a ious a same ime.
In sec ions 5.2 and 5.3.2 /e c/ c.local has been widely explained so i s ea u es and whe e-
abou s will no be discussed again in his sec ion.
Wha his op ion oe s as a new ea u e is he use o a G aphic In e ace o manage all he
nodes (s a , eboo , shu down), his means ha o a use non amilia wi h shell en i onmen s
i becomes easie o manage nodes because o he GUI, wi h jus one mouse click he nodes a e
con olled.
The main die ence be ween his op ion an he one in sec ion 5.3.2 is he absence o a sc ip
asking he use inpu da a in o de o de e mine he nal beha io . Ins ead o ha he e is a
GUI. This op ion aims o p o ide a be e use in e ace usage.
37
5.4. Final op ion: Use o /e c/ c.local + Ja a GUI + Bash sc ip s
Figu e 5.5: Ja a GUI
5.4 Final op ion: Use o /e c/ c.local + Ja a GUI + Bash sc ip s
Th ee possible op ions ha e been desc ibed as a solu ion o he IP 6 Ne wo k Mobili y Tes bed.
1. Use o C on + Bash sc ip s
2. Use o /e c/ c.local + Bash sc ip s
3. Use o /e c/ c.local + Ja a GUI + Bash sc ip s
One o he equisi es was ha he usage o he es bed congu a ion, swi ching ei he physical
nodes o VM's on had no o be a ha d ask. Fo ha eason he use o a Ja a GUI
( hi d solu ion)
has been decided as he bes op ion o hose pu poses.
5.4.1 Die en ea u es o he Ja a GUI
In sec ion 5.3.2 i was said he e we e wo main die en scena ios beha io s,
Simula ing a
sa elli e link and BGAN sa elli e link
. I was men ioned ha he es bed uses some XEN VMs,
depending o which scena io beha io has o be es ed hose XEN VMs will need a die en
38
5. Tes bed Au oma ion
congu a ion le (.c g) o be loaded. In his .c g le he e a e all he in o ma ion o he VM, he
OS image (img) i uses, which in e aces has o be congu ed, MAC add esses o ensu e hey a e
unique and he e is no conic , also which b idges a e congu ed and o he hings.
Howe e , as he NEWSKY p ojec was going o nish wi hin some weeks and he es bed
a chi ec u e was going o change in a close u u e i was nally decided no o de o e some many
ime in ha . The e o e some decisions we e aken. One o hem was he decision o le ing
as p econgu ed he Sa elli e emula ed link beha io , ha means he VMs s a s au oma ically
wi h he co esponden .c g le, in he GUI he e is no op ion o change ha , howe e in a u u e
ex ension and adap a ion o he GUI o he new SANDRA es bed a chi ec u e i could be done.
A node is supposed o be up i i ullls he ollowing equi emen s:
1. I is eachable h ough he ne wo k (3 ICMP packe s a e sen using
ping -c 3
)
2. All he p ocesses wi hin a lis a e unning in he node
The ow om below, gu e 5.6 exemplies how he s a us o a node is checked.
Figu e 5.6: Flow Checking Nodes S a us
To check i whe he a p ocess is unning o no a shh connec ion is deployed and a e wa ds
a Unix command is execu ed. This Unix command ies o iden i y a namep ocess in he emo e
39
5.4. Final op ion: Use o /e c/ c.local + Ja a GUI + Bash sc ip s
node, he name o he p ocess is he one ha is ex ac ed om lp ocess.ge (i). The line om
below desc ibes wha has been explained in his pa ag aph.
ssh o[email p o ec ed] ps -e | g ep " + lp ocess.ge (i) + " | -s /" /" | cu -d /" /" - 5
The ollowing ow cha gu e 5.7 shows he ow when a s a ac ion is called om he GUI.
Bea in mind ha in he
C ea e HA VM
box in he inne code i is es ablished o use Sa elli e
Link Emula ion congu e le (.c g). In a u u e ex ension i can be p og ammed a unc ionali y
o change among his and he o he .
Figu e 5.7: Flow S a Node
The ollowing ow cha gu e 5.8 shows he ow when a s op ac ion is called om he GUI.
In he box 
Shu down XEN ID VM
 a shu ing down ac ion is pe o med in Humbold node.
Humbold node alloca es die en VMs in i s domain, so wha is done in he 
Shu down
XEN ID VM
 box is once he iden ie o he VM wi hin Humbold is cap u ed i is used o
iden i y he VM o be s opped. The command o s op he XEN VM is he one in gu e 5.9.
40
5. Tes bed Au oma ion
Figu e 5.8: Flow S op Node
Figu e 5.9: S op VM command
The ow cha om gu e 5.10 exemplies he case when a node is being eques ed o be
eboo ed. I he node is no a ailable because i is down hen i can no be eboo ed, o he wise
he eboo ing p ocess is ollowed
5.4.2 Whe e a e he sc ip s loca ed and how a e hey execu ed ?
Ha dly all he sc ip s in a node a e loca ed in a specic pa h olde di ec o y, his gua an ees he
sc ip s o be s o ed in he sub e sion, making i possible o easily ees ablish all he sc ip s les
in case o a majo disas e . I can be said ha hey a e all cen alized in a di ec o y ins ead o
being sp ead along he node pa h di ec o y ee.
In sec ion 5.3.3 i has been explained ha sc ip s a e p e iously p edened in he /e c/ c.local
sc ip le. Two hings ha e o be conside ed, one is ha he ac ual congu a ion akes in o ac-
coun ha as a p econgu ed congu a ion is being used hen he equi ed sc ip s a e dened in
41

5.4. Final op ion: Use o /e c/ c.local + Ja a GUI + Bash sc ip s
Figu e 5.10: Flow Reboo Node
he /e c/ c.local. The o he hing o ake in o accoun is ha i is easily easible o ex end and
modi y he code o make ha ins ead o dening some sc ip s in he /e c/ c.local hey nally
become execu ed by he GUI applica ion by e oking hem emo ely.
The Ja a GUI app can be execu ed om ou side he es bed, he e is no need o launching
i om a es bed node. Howe e some p e ious s eps a e needed o be ollowed. Those s eps a e
mainly congu ing a eliable shh key in e communica ion channel. I is achie ed by c ea ing an
own ssh key
ce i ica e8
copy i o he es bed nodes he compu e will connec and also copy
he ssh key-ce ica es om he es bed nodes o he local compu e .
Ano he s ep ha needs o be done is copy he ja a GUI les om he sub e sion unk o
om one o he es bed nodes ha has he ja a les in he e.
42
Chap e 6
NeXT so wa e a chi ec u e/design
In his chap e some aspec s o NeXT  s e sion ( he p e ious one o my p ojec ) design will
be explained o a be e comp ehension. Which changes ha e o be in oduced in o NeXT  s
e sion in o de o adap i o he new SANDRA scena io will be also explained. And nally,
wo die en NeXT new design app oaches will be desc ibed.
6.1 NeXT  s p o ocol e sion design
As i has been men ioned in sec ion 4.3 in a p e ious chap e , NeXT  s code was hough
o a one- o-one communica ion, i means NeXTMas e has only communica ion exchange wi h
one NeXTSla e and ice e sa. NeXTMas e only sees NeXTSla e and his las one only sees
NeXTMas e .
Figu e 6.1 shows an example o NeXT deploymen in a ypical opology ne wo k in eal
wo ld.
Figu e 6.1: NeXT eal wo ld a chi ec u e
43
6.2. New NeXT equi emen s in SANDRA scena io
Figu e 6.2: NeXT eal wo ld using sa elli e link
Figu e 6.2 shows a scena io using a sa elli e link wi hin T iaGnoSys GmbH company ne wo k,
using an AR wi h NAT as an en y ga eway o he company ne wo k.
NeXT uses some esou ces in o de o make he ansla ion om IP 6 packe o an IP 4
packe and he way ound. These esou ces a e ela ed wi h p ocesses iden ie s, add esses
in o ma ion and also some da a s uc u es ha holds he in o ma ion equi ed o ha e an IP 6-
IP 4 mapping as commen ed in sec ion 4.1.3.
NeXT64(ei he NeXT64_Mas e o NeXT64_Sla e) and NeXT46 (ei he NeXT64_Sla e
o NeXT46_Sla e) holds i s own da a s uc u e which is in cha ge o keeping he in o ma ion
equi ed o a packe ansla ion (one way IP 6 o IP 4 o NeXT64 and he o he way, IP 4 o
IP 6 o NeXT46).
Apa om ha NeXT uses
SIGNALS9
o le NeXT46 en i y and NeXT64 en i y exchange
in o ma ion among hem. Mo eo e SIGNALS a e used o a p ope e mina ion o NeXT p o-
ocol unde demand, when an o de o e mina ion is sen o NeXTMas e his one sends a
no ica ion o i s NeXTSla e in e locu o saying ha i is going o go down un il new no ica-
ion. NeXTSla e hen cleans i s con ex ela ed wi h i s NeXTMas e in e locu o .
Some ows, will be shown o gi e a glance o how NeXT wo ks, bu jus as example gi en.
Please see gu es 6.3 and 6.4
6.2 New NeXT equi emen s in SANDRA scena io
As men ioned in sec ion 4.3 NeXT has been chosen as he op ion o be deployed in SANDRA
scena io. As a esul o his i can be seen in gu e 4.9 how does NeXT look like in his new
scena io. Things o poin ou , assuming ha only one MR is being conside ed, a e:
1. The e a e mul iple NeXTMas e ins ances in he same MR
2. The e is one NeXTSla e in each Region Ne wo k A ea (see gu e 4.9)
44
6. NeXT so wa e a chi ec u e/design
Figu e 6.3: NeXT64 Mas e ow
Wha do his wo las poin s mean? I means ha he way NeXT wo ked be o e in i s
 s elease e sion is no longe alid anymo e due o he exis ence o mul iple NeXTMas e
ins ances in MR. In sec ion 6.1 i has been said ha NeXT was o iginally hough o a one- o-one
p o ocol, his has some coding implica ions in e ms o NeXT own esou ces managemen and
NeXT in e -en i ies communica ion (NeXT46-NeXT64 communica ion ow).
As an example gi en, i NeXT46 wan ed o communica e some in o ma ion o NeXT64 i
looked in he Linux p ocess lis by using he command
ps
piped wi h o he commands, and i
sea ched o a p ocess called NeXT64_Mas e . This p oceeding didn' ep esen a p oblem
o beha io in a one- o-one mode ope a ion, howe e , as MR has u ned in o an en i y wi h
mul iple NeXTMas e ins ances he p oceeding p e iously explained would be p oblema ic and
would lead o a non s able beha io and pe o mance. Fo ins ance, o a be e comp ehension in
he ollowing example i is assumed ha MR has wo NeXTMas e ins ances (2 x NeXT64Mas e
and 2 x NeXT46Mas e ), le s call hem:
•
NeXT64Mas e _1
•
NeXT64Mas e _2
•
NeXT46Mas e _1
•
NeXT46Mas e _2
45
6.3. Two die en NeXT design app oaches
ha dcoded) and each ins ance needs a die en in e ace congu a ion in o de o wo k. This
ha dcoding o he in e aces was done by dening in a .h le a se o in e aces using
denes
10
,
as his le is included in almos all he les hey can be used.
NeXT uses
pugixml11
, i is a ligh -weigh C++ XML p ocessing lib a y. I is de eloped and
main ained since 2006 and has many use s. All code is dis ibu ed unde he MIT license, making
i comple ely ee o use in bo h open-sou ce and p op ie a y applica ions. NeXT p o ocol is
coded in
C
language, howe e he NeXT launche is coded in C++, and i is he NeXT launche
ha uses pugixml, o C les i is some hing anspa en . The eason o using C++ in he
launche ins ead o C language is due o he in en ion o using h eads, using he C lib a y
p h ead.h
, in NeXT h eads an encapsula ion using his lib a y was made in o de o make he
code mo e objec o ien ed.
Lea ing his ma e o pugixml usage, in o de o add his dynamism o NeXT he ollowing
modica ions we e done, gu e 6.9 shows a po ion o he o iginal code in he .h le p e iously
men ioned.
Figu e 6.9: In e aces ha dcoded
To add dynamism
ex e n a iables
a e used, hey ge he alue om uppe
c les
(NeXT64
and NeXT46 en i ies which ecei ed he in o ma ion as inpu pa ame e s, he ones ead om
he xml congu a ion le). In gu e 6.10 i can bee seen.
Figu e 6.10: In e aces ha dcoded wi h dynamism
When an
ex e n a iable
is decla ed, he compile is old ha he a iable was dened
elsewhe e. The compile is old ha a a iable by ha name and ype exis s, bu he compile
should no alloca e memo y o i since i is done somewhe e else. The ex e n keywo d means
"decla e wi hou dening". In o he wo ds, i is a way o explici ly decla e a a iable, o o o ce
a decla a ion wi hou a deni ion. When a
#dene
is done i alloca es memo y ha emains
un il he p og am nishes i s execu ion.
I exis s a xml congu a ion le pe each NeXT wo king mode, an xml le is loaded depending
on he pa ame e s gi en o he NeXT launche execu ion:
./NeXT s a 3 mas e sa 1
I
mas e
and
sa
hen
Sa elli e mas e
mode is loaded. All he possible modes a e lis ed below:
•
Sa elli e mas e
52

6. NeXT so wa e a chi ec u e/design
•
Sa elli e sla e
•
Sa elli e emula ion mas e
•
Sa elli e emula ion sla e
Be o e his
NeXT mul ip ocess app oach
NeXT had ou launching sc ip s, each one o each
o i s wo king mode. In his sc ip s some pa ame e s had also o be gi en. So, whene e NeXT
had o be launched i had o be hough which sc ip s was he co ec one. Now, by using he
NeXT launche his is educed o a only one bina y le.
In he ea lie pa ag aphs o his sec ion i has been men ioned he use o
p ocess numbe
iden ie
(PID) in o de o bo h kill NeXT ins ances unning and send a SIGNAL o a specic
NeXT en i y. This PID in o ma ion was s o ed in le sys ems and ead by NeXT64 and NeXT46
en i ies. Sending a SIGNAL o a specic NeXT ins ance now is no as easy as sea ching one
name p ocess, now i is done by eading he PID om a le in he sys em, his in oduces one
p oblema ic si ua ion which is
¾How can i be gua an eed ha he le ha holds he PID has been
c ea ed¾`
. I he le has no been c ea ed hen he e is no way o eading he PID o he en i y
i is in ended o send SIGNALS. I is sol ed by applying some hing simila o a handshaking
p ocess. Figu e 6.11 shows how i is done.
Figu e 6.11: PID Handshaking
6.4 Th eads In oduc ion
6.4.1 Wha is a Th ead
A h ead is an applica ion ask ha is execu ed by a hos compu e a he same ime as o he s.
I is an independen s eam o ins uc ions ha can be scheduled o un as such by he ope -
a ing sys em. Fo ins ance, imagine a main p og am ( h eadi.bin) ha con ains a numbe o
53
6.4. Th eads In oduc ion
Figu e 6.12: UNIX h ead
p ocedu es. Then imagine all o hese p ocedu es being able o be scheduled o un simul ane-
ously and/o independen ly by he ope a ing sys em. Tha would desc ibe a "mul i- h eaded"
p og am. In gu e 6.12 an UNIX p ocess s uc u e and an UNIX THREAD is shown.
Th eads sha es memo y among hemsel es, i means almos all a iables and in o ma ion
a e sha ed. Th eads can ha e i s p i a e da a hough. In gu e 6.13 shows in la ge scale his
las asse ion.
Things o bea in mind abou h eads:
•
Has i s own independen ow o con ol as long as i s pa en p ocess exis s and he OS
suppo s i
•
May sha e he p ocess esou ces wi h o he h eads ha ac equally independen ly
•
Dies i he pa en p ocess dies
•
Is "ligh weigh " because mos o he o e head has al eady been accomplished h ough he
c ea ion o i s p ocess.
•
Changes made by one h ead o sha ed sys em esou ces (such as closing a le) will be seen
by all o he h eads.
•
Reading and w i ing o he same memo y loca ions is possible, he e o e equi es explici
synch oniza ion.
54
6. NeXT so wa e a chi ec u e/design
Figu e 6.13: Th ead Memo y
6.4.2 Why using h eads?
I has become a g owing up op ion du ing las decade and i p o ides appealing pe o mance
esul s in mul i h eading capable nodes and nowadays almos all nodes a e mul i h eading. I
allows o ha e a be e esou ce managemen .
His o ically, h eading was  s exploi ed o make ce ain p og ams easie o w i e. I a
p og am can be spli in o sepa a e asks, i 's o en easie o p og am he algo i hm as sepa a e
asks o h eads. NeXT didn' ma ch his desc ip ion since wha i did was ollow a sequence
o ins uc ions o ea ing a packe . The idea o using h eads in NeXT was o sa e space in
e ms o memo y and a be e pe o mance aking ad an age o nowadays mul i h eading nodes
capabili ies.
Why sa ing space? NeXT new e sion needs o launch mul iple NeXTMas e en i ies, his
means o each NeXTMas e en i y he e is a memo y space o be alloca ed, depending o he
ca dinali y o he #NeXTMas e en i ies his can become some hing c i ical i he numbe o
ARs is big enough .
6.4.3 Wha is p h ead lib a y?
P h eads a e a se o C language p og amming ypes and p ocedu e calls ha NeXT h eads
uses.
55
6.5. NeXT h eads
Ha dwa e endo s ha e implemen ed hei own p op ie a y e sions o h eads o yea s.
These implemen a ions die ed subs an ially om each o he making i dicul o p og amme s
o de elop po able h eaded applica ions. In o de o ake ull ad an age o he capabili ies p o-
ided by h eads, a s anda dized p og amming in e ace was equi ed. Fo UNIX sys ems, his
in e ace has been specied by he IEEE POSIX 1003.1c s anda d (1995). Implemen a ions ad-
he ing o his s anda d a e e e ed o as POSIX h eads, o P h eads. Nowadays mos ha dwa e
endo s now oe P h eads in addi ion o hei p op ie a y API's. The la es e sion is known
as IEEE S d 1003.1, 2004 Edi ion.
6.5 NeXT h eads
Figu e 6.14: Th ead Memo y
Figu e 6.14 shows he NeXT h ead design a chi ec u e, i can be app ecia ed ha i is
simila o he one in
NeXT mul ip ocess
(see sec ion 6.7). In
NeXT h eads
bo h NeXT Main
P ocess and child p ocesses emains ali e un il a e mina e signal is sen . The eason is ha as
a h ead uses he p ocess memo y space, i i s p ocess ( he one ha has c ea ed i ) disappea s
hen he h ead has no memo y space.
NeXT64 and NeXT46 en i y ha e each one a da a s uc u e ha holds he in o ma ion
equi ed o ansla e packe s om IP 6 o IP 4 and ice e sa. This da a s uc u es ollows he
concep o
ex e n a iables
explained in sec ion 6.3.1, hey a e dened as global a iables in
NeXT64 and NeXT46 en i ies (bo h has i decla ed wi h he same name) and whene e someone
wan s o use his da a s uc u e i has o decla e i as ex e n. In
NeXT mul ip ocess design
his
means ha e e y da a s uc u e is unique and he e is no conic o names due o he ac ha
NeXT64 is a p ocess and NeXT46 is ano he independen p ocess. The esul is he ollowing
one om he gu e 6.16, he e is a link o union be ween NeXT64 and NeXT lib a y (inside is
called ex e n ype_da a_s uc u e name), and ano he link die en be ween NeXT46 and he
NeXT lib a y. These die en links a oid name conic s wi h he da a s uc u e.
Howe e in NeXT h eads he e is one big p oblem, bo h NeXT64 and NeXT46 ha e a
da a s uc u e decla ed wi h he same name s uc ab able in a global way. As in h eads
56
6. NeXT so wa e a chi ec u e/design
en i onmen he e is he sha ed concep in oduced in sec ion 6.4.1, bo h decla a ions gene a es
a name conic decla a ion because he e a e wo a iables wi h he same name, s uc ab
able om NeXT64 sees he one om NeXT46 and ice e sa. I also happens wi h he me hods
in he NeXT lib a y as i can be seen in he gu e 6.16.
In o de o sol e his p oblem, I hough o wo op ions:
1. Use a common able o bo h NeXT64 and NeXT46
2. Decla e one s uc ab wi h a unique name, s uc ab able o NeXT64 and s uc
ab able_4 o NeXT46
The  s op ion was hough because o he sha ed memo y ea u e, his allowed he wo
en i ies sha e he same esou ce and i simplied some code aspec modica ions in NeXT lib a y.
Howe e , sha ing he same esou ce had he ollowing implica ions:
•
Same esou ce o bo h en i ies makes he concu ency o eads and w i es aise, ( his adds
such a le el o complexi y ha he numbe o eads and w i es in he da a s uc u e a e
less han i wo da a s uc u es a e used due o locks o da a in eg i y).
•
NeXT64 s uc ab able had an o de inside i s specica ion o each o i s elds. NeXT46
s uc ab able had o he o de .
Poin wo implied ha almos all he code had o be changed, and he e was no gua an ee
ha i would ha e wo ked because he e we e so many hings o be changed. NeXT code made
a s ong use o i s da a s uc u e ha hos s he in o ma ion equi ed o packe s ansla ion,
hus i was like ew i ing a big po ion o he code. Doing his would ha e ep esen ed ha
iden i ying bugs in case o showing hem up would ha e been dicul . The p io i y was o ha e
a wo king NeXT solu ion in ime. This op ion men ion dec eased he o e all o w i es and eads
in a ce ain pe iod ime due o he gh ing o he common esou ce and locking aspec s.
Figu e 6.15: NeXT mul ip ocess able linkage
57

6.5. NeXT h eads
Figu e 6.16: NeXT h eads able linkage
Decla e one s uc ab wi h a unique name, s uc ab able o NeXT64 and s uc ab
able_4 o NeXT46 was wha was mo e easible and was de eloped in a nal e m. Wi hin
NeXT lib a y he e we e some me hods exclusi ely used by NeXT64 and o he s only used by
NeXT46, his allowed a die en ia ion be ween s uc ab able o NeXT64 and s uc ab
able o NeXT46.
The e was a p oblem wi h he
le desc ip o a iable
, i happened he same p oblem as he
s uc ab able. The e was a global le desc ip o a iable dened in NeXT64 named
d_log
,
bu he e was ano he global le desc ip o a iable named
d_log
in NeXT46. Due o he sha ed
memo y concep he e was a
name collision
. Fo ha eason he die en ia ion be ween d_log
in bo h NeXT64 and NeXT46 was done, bu only in hose wo. The le desc ip o a iable is
used in a unc ion inside he NeXT lib a y me hods, his me hod is:
•
in W i eLog( DebugLe debgle , cha *s ,...)
Inside his unc ion an
ex e n FILE * d_log
is done. To sol e he p oblem he W i eLog
unc ion had o change, u ning in o:
•
in W i eLog( DebugLe debgle , FILE* d_log, cha *s ,...)
The e o e, he
d_log
a iable had o be sp ead among he me hods ha used he W i eLog
unc ion in o de o be used,
ex e n
a iable was no used anymo e.
The e is a well known saying ha says, y no o me ge SIGNALS and h eads because i
ends o be e y icky and a good pe o mance and co ec execu ion o he code can ne e be
gua an eed. SIGNALS wi h h eads is no some hing e y ecommended, a leas he e a e so
many opinions abou ha . One o he main easons, no he only one, is he ollowing one. I
he e a e h ee h eads, le 's say
T1, T2, T3,
wai ing o a specic SIGNAL, le 's say
SIGUSR1
SIGNAL. I he h ee h eads ha e been c ea ed in he same p ocess hen, i a SIGUSR1 is
58
6. NeXT so wa e a chi ec u e/design
in ended o be sen o T1, i can no be done he assump ion ha he SIGNAL will each T1.
The esul will be some hing andom. When a h ead is c ea ed in a p ocess he p ocess is he
one ha handles SIGNAL ecep ion. Whene e he p ocess ecei es a SIGNAL i looks i he e
is some h ead wai ing o his specic ype o SIGNAL,
SIGUSR1
in ou case. I he p ocess
has he in o ma ion ha he e is a leas one h ead wai ing o he specic ype o SIGNAL, he
p ocess deli e s he signal andomly o one o he h eads ha a e wai ing o he SIGNAL.
By di iding he memo y space o each NeXT pai he p oblem scale is educed o wo
h eads, bo h NeXT64 and NeXT46 sha e some SIGNALS ype, hus en emula ion o SIGNAL
p oceeding was done.
Figu e 6.17: NeXT h eads SIGNALS
In gu e 6.17 i can be seen he design wi h his new SIGNAL emula ion. The way i wo ks
is he ollowing one.
•
NeXT64 c ea es he NeXTala m h ead which pe iodically sends in o ma ion o he MR o
NeXTSla e in o de o keep he communica ion ali e and i s s a us. This in o ma ion is
sen ia UDP packe s upon NeXTala m eques .
•
NeXT NeXT64 c ea es he NeXT eques h ead and when NeXT46 ecei es a eques om
NeXTSla e, NeXT46 no ies he
NeXT eques h ead
ha a eques has been s o ed in i
and ha i can ead i now. This no ica ion is sen by using 
p h ead_cond_signal(p h ead_cond_
*cond)
 p h ead unc ion and an emula ion o semapho es wi h locks. Fo u he in o -
ma ion isi he 
p h ead_cond_signal(3) Linux man page
.
59
6.6. NeXT design chosen
•
NeXT eques h ead eads he eques , makes i s local asks and no i y NeXT46 ha i
has nished and ha i can con inue again wi h i s asks.
•
NeX eques h ead wai s o ano he no ica ion
Doing like his he SIGNAL beha io is emula ed. I has o be said ha SIGNAL emula ion
o SIGTERM was no implemen ed. The e we e some s ange beha io s such as ha a e
NeXTMas e had sen he  s packe ( he one ha ells NeXTSla e some in o ma ion abou
NeXTMas e ) o i s NeXTSla e, no ou e s ad e isemen s we e obse ed. Ins ead o ou e
ad e isemen s he e we e some packe s ha seemed UDP da a packe s bu hey we e conside ed
by he NeXTMas e as ou e ad e isemen s (Ra) when in he Wi esha k sning ool hey didn'
appea as Ra. My guess is ha he p oblem was due o a sha ed esou ce wi hin he code, in
cha ge o handling eques s.
6.6 NeXT design chosen
NeXT mul ip ocess has been chosen as he nal op ion. I is simple han NeXT h eads, i
wo ks, and i can be easily ex ended, modied, adap ed and also main ained. NeXT h eads im-
plemen a ion implied a non easy going code and a code no easily main ainable. Howe e h ead
echnology can con ibu e o good pe o mance in a u u e NeXT e sion which is some hing
good o conside in a close u u e. One o he objec i es was o make NeXT and ROHC wo king
oge he a he same ime in he es -bed and i has been accomplished.
Robus Heade Comp ession (ROHC) is a s anda dized me hod o comp ess he IP, UDP,
RTP, and TCP heade s o In e ne packe s. I pe o ms well o e links whe e he packe loss
a e is high,such as wi eless links.
In s eaming applica ions, he o e head o IP, UDP, and RTP is 40 by es o IP 4, o 60
by es o IP 6. Fo VoIP his co esponds o a ound 60% o he o al amoun o da a sen . Such
la ge o e heads may be ole able in wi ed links whe e capaci y is o en no an issue, bu a e
excessi e o wi eless sys ems whe e bandwid h is sca ce.
The e is in o ma ion in heade s ha can be p edic ed, he e is in o ma ion ha is always he
same, he e is o he in o ma ion ha can be p edic ed such as he sequence numbe o a packe
in a specic ow. Howe e he e is o he in o ma ion ha can no be p edic ed because he e is
no pa e n o p edic . ROHC ake ad an age o his dynamic elds in heade s o sa e space, i
con e s hem in o a sequence numbe in he comp esso and he decomp esso in e p e s hem.
ROHC comp esses hese 40 by es o 60 by es o o e head ypically in o only 1 o 3 by es
by placing a comp esso be o e he link ha has limi ed capaci y, and a decomp esso a e ha
link. The comp esso con e s he la ge o e head o only a ew by es, while he decomp esso
does he opposi e. In SANDRA scena io using NeXT he comp esso was placed a MR and he
decomp esso a HA. ROHC heade s a e placed in lowe bi s han NeXT heade s, hus NeXT
heade s a e applied a e ROHC p o ocol is applied o he packe . I can be said ha NeXT
heade s ac s as a unnel ca ying ROHC heade s. Bo h MR and HA can ac as ei he comp esso
o decomp esso .
60
Chap e 7
Tes Cases
The es cases ha will be analyzed a e wo,
Case1 (7.1)
and
Case2 (7.2)
. Ini ially The e we e
mo e es cases, howe e all o hem could be summa ize as Case 1 (7.1), so hey we e no
specied in he epo . Tes cases analyzed a e s uc u ed as ollows.
An explana ion o which is he
Aim
o doing he es in he specic case is ini ially p esen ed.
The e is a e wa ds an enume a ed lis o s eps desc ibing he congu a ion o he scena io and
he s eps ha a e aken o p oduce changes in ha beha io . A e his lis i is shown he
expec ed esul s
o he es ing and he
eal esul s obse ed
a e applying all s eps in he es ing.
Finally he e is a echnical discussion abou
eal esul s obse ed
, and i i does no ma ch wi h
he
expec ed esul s
an explana ion o why bo h wo esul s do no ma ch is gi en.
In his epo a gu e o he cu en es -bed was p e iously p esen ed, i is gu e 5.1.
Consul ing gu e 5.1 allows o ollow easily explana ions gi en a e he
esul s obse ed
pa in
he specic case. I also helps on he unde s anding o he ini ial congu a ion o he es -bed
specied in he enume a ed lis . I is ecommended o consul gu e 5.1, i can be used as
suppo ma e ial.
7.1 Case 1
Aim o he es case:
Demons a e ha wi h a s a ing scena io whe e wo AR 4 a e up and
ac pass h ough hem, i one AR goes down ac is edi ec ed o he o he AR link.
1. MR-AR1 and MR-AR2 links using IP 4 a e up.
2. Ping om MNN SCgW o CN SCgW.
61
8.2. Fu u e wo k
and has shown posi i e esul s. I p o ides an in e ace o he nal use o some hing ha is
echnical indeed bu i can be seen as some hing less complex and easy o manage. This GUI is
no a nal elease, i is a young ool ha has been concei ed, a ool hough o being ex ended
and also easy main ained and modied o o he pu poses (e.g. changes in he es -bed opology
a chi ec u e, p ocess o passing om NEWSKY p ojec o SANDRA p ojec ).
8.2 Fu u e wo k
The
G aphic Use In e ace
is a ool ha can be ex ended and adap ed o new es -bed opolo-
gies. Some unc ionali ies in he cu en GUI we e disca ded due ime and objec i es, he main
objec i e was o dene an ini ial and ope a i e base ool. Ac ions such as changing he ype o
he link ha he MR uses can be done om he GUI ( his unc ion was implemen ed bu was
no ull ope a i e).
O he asks ha can be done is o p o ide SNMP capabili ies o he es -bed nodes o an
easy moni o ed con ol.
The es -bed uses XEN hype iso , i uses XEN VM hus hese VM has a limi a ion o 8
in e aces each one. This is a echnical limi a ion documen ed in XEN web page ha limi s he
es bed because i only allows o ha e wo NEMO unnel in e aces, his has been explained
in sec ion 7.1. I would be o in e es o nd a way o eplace he wo in e aces dedica ed o
Mip6d, he idea would be o use ap in e aces. A ap is a loopback in e ace ha wo ks in laye
2. Some a emp s we e done o make i wo k bu hey we e unsuccess ul.
An ex ension o he cu en NeXT implemen a ion could be adding he unc ionali y o
launching and specic NeXT ins ance bound o an AR ins ead o always elaunching all p e iously
dened in he xml congu a ion le.
One o he objec i es ha has no been ullled is u ning NeXT in o h eads due o echnical
easons. Tu ning i in o h eads is some hing appealing howe e , hings such as easy code
upkeeping and code easy o unde s and ha e o be conside ed o decide whe he i is wo h o
no .
NeXT is an ecien echnology applied o IP 4 a e sal, and i is wi hou any doub a
solu ion ha can help in o he in e media e p ocess o mig a ion om IP 4 o IP 6.
68

Chap e 9
Re e ences and Bibliog aphy
Re e ences
1. RFC 2460, In e ne P o ocol, Ve sion 6 (IP 6) Specica ion
2. RFC 2374, An IP 6 Agg ega able Global Unicas Add ess Fo ma
3. RFC 4301, Secu i y A chi ec u e o he In e ne P o ocol
4.
h p://www.inma sa .com/Se ices/Land/BGAN/de aul .aspx
5.
h p://na isbad.o g/m6 /
6. RFC 5555, Mobile IP 6 Suppo o Dual S ack Hos s and Rou e s
7.
h p://www.nau ilus6.o g/
8. Linux man page ssh-keygen
9. Linux man page signal
10. h p://www.cp og amming.com/ e e ence/p ep ocesso /dene.h ml
11. h p://pugixml.o g/
69
Bibliog aphy
12. RFC3095 (ROHC)
13. RFC 3963 (NEMO)
14. RFC 3775 (Mobile IP 6)
15. Unde s anding IP 6, Au ho : Joseph Da ies, Mic oso P ess (Book)
16. P og amming wi h POSIX(R) Th eads, Au ho : Da id R. Bu enho (Book)
17. Quade n de Labo a o i de Xa xes de Compu ado (Book)
Au o s: Llo enç Ce dà-Alabe n i José M. Ba celó-O dinas
Depa amen d'A qui ec u a de Compu ado s, Enginye ia en In o mà ica
Re . 44301
18. Xa xes de Compu ado s, Concep es bàsics (Book)
Au o : Llo enç Ce dà Alabe n
Edicions UPC
19. Linux IP 6 S ack Implemen a ion Based on Se ialized Da a S a e P ocessing (Pape )
Hideaki YOSHIFUJI, Kazuno i MIYAZAWA, Masahide NAKAMURA, Yuki SEKIYA, Hi-
oshi ESAKI, Jun MURAI.
VOL.E87-B,NO.3 MARCH 2004
20. USAGI IP 6 IPsec De elopmen o Linux (Pape )
Mi su o Kanda, Kazuno i Miyazawa, Hi oshi Esaki
21. Ve sa ile IP 6 Mobili y Deploymen wi h Dual S ack Mobile IP 6 (Pape )
Romain Kun z, Jean Lo cha
22. IP 6 IPsec and Mobile IP 6 implemen a ion o Linux (Pape )
Kazuno i Miyazawa, Masahide Nakamu a
23. Ai T ac Managemen Ne wo k Based on IP 6 P o ocol S ack (Pape )
E iza Had Fazli, Àngels Via Es em, Nú ia Rie a Díaz
24. IP O e head Compa ison in a Tes -bed o Ai T ac Managemen Se ices (Pape )
E iza Had Fazli, Àngels Via Es em, Nú ia Rie a Díaz, Sèbas ien Duo , Ma kus We ne
25. The concep o obus heade comp ession, ROHC (Whi e Pape )
EFFNET AB
26. An in oduc ion o IP heade comp ession (Wi e Pape )
EFFNET AB
27. Mobile IP 6 Technology Re iew (Documen )
Lancas e Uni e si y
70
9. Re e ences and Bibliog aphy
28. IP 6 Ne wo king O e Sa elli e Fo Mobile Use G oup (Pape )
Àngels Via Es em, Axel Jahn
29.
h p://umip.linux-ip 6.o g/index.php?n=Main.HomePage
, [mip6d webpage]
30.
h p://www.cplusplus.com
31.
h p://s acko e low.com
32.
h p://www. iagnosys.com
33.
h p://www.debian.o g
34.
h p://www.linuxques ions.o g
35.
h p://www.xen.o g
36.
h p://www.ne beans.o g
37.
h p://www.eclipse.o g
38.
h p://li e.gnome.o g/Dia
No e:
- All RFC in bo h
Re e ences
and
Bibliog aphy
ha e been ead
- (Links las isi - 23-03-2011)
71