Towards Expeditious and Unswerving Routing to Corroborate Nascent Internet

The internet is now-a-days experiencing a stress due to some inherent problems with the main interdomain routing protocol, boarder gateway protocol (BGP), the amount of time it takes to converge, number of update message exchanged followed by a failu…

Authors: Shishir Kumar, Mahesh Kumar

JOURNAL OF COMPUTING, VOLUME 1, ISSUE 1, DECEMBER 2009, ISSN: 2151-9617 HTTPS://SITES.GOOGLE.COM/S ITE/JOURNALOFCOMPUTING/ 114 T owards Expeditious and Unswerving Routing to Corroborate Nascent Internet Dr Shishir Kumar , Mahesh kumar Abst ract —The internet is now-a-days experiencing a stress due to so me inherent problems with the main interdomain routing protocol, boarder gateway pro tocol (BGP), the a mount of ti me it takes to converge, number of u pdate message exchanged followed by a failure to stabilize, t he amount of time required to get a valid alternate path following the failure, the way si ze of routing table increasing, and security issues like integrity and privacy of routing t ables and routing updates exchanged among the routers, are of our primary concern. In our proposed res earch work we plan to address aforem entioned issues related to internet routing specially in boarder gateway protocol to enabl e BGP to offer expeditious unswe rving routing to corroborate nascent internet. We plan to make some changes in the desi gn of boarder gateway protocol and may introduce additi on of extra features in BGP to help suppor t above mentioned objective. Index T erms — Computer Networks, internet routing, BGP , internet gr owth, routing protocols, rout ing tables, routing updates, convergence time ——————————  —————————— 1 I NTRODUCTION HE structure  of  the  internet  is  a  is  a  collection  of  networks,  or  Autonomous  Systems  (AS’ s),  as  shown  in  figure1  and  2,  which  are  interconnecte d  to  form  a  connected  domain  [19].  Each  AS  uses  an  interior  routin g  system  to  maintain  a  coherent  view  of  the  topology  within  the  AS,  and  uses  an  exterior  routing  system  to  maintain  adjacency  information  with  neighboring  AS’ s  and  thereby  create  a  view  of  the  connectivity  of  the  entire  system.  This network-wide connectivity is described in the routing table used by the BGP4 protocol. Each entry in the table refers to a distinct route. The attributes of the route are used to determine the best path from the local AS to the AS that is originating the route. Determining the ’best path’ in this case is determining which routing adver- tisement and associated next hop address is the most pre- ferred. The BGP routing system is not aware of fine r level of topology within the local AS or within any remote AS. From this perspective BGP can be seen as a connectivity maintenance protocol, and the BGP routing table, a de- scription of the current connec tivity of the Internet, using an AS as the basic element of computation. Figure 1: Autonomous Systems T ——————————————— — • Dr Shishir Kumar is Head of the Department of Computer Science and Engineering, Jaypee Institute of Engineeringv and Technology, Guna, Madhya Pradesh (India). • Mahesh Kumar is with the Department of Computer Science and Engineer- ing, Jaypee Institute of Engineeri ngv and Technology, Guna, Madhya Pradesh (India). © 2009 Journal of Computing http://sites.google.com/site/jo urnalofcomputing/ JOURNAL OF COMPUTING, VOLUME 1, ISSUE 1, DECEMBER 2009, ISSN : 2151-9617 HTTPS://SITES.GOOGLE.COM/S ITE/JOURNALOFCOMPUTING/ 115 Figure 2: Multi-tier inter-dom ain routing 2 RELA TED WORK: Different  authors  have  tried  different  approaches  to  overcome  issues  in  internet  routing  problem s,  and  each  one  has  claimed  to  achiev ed  better  performa nce  by  either  introducing  new  approaches  or  by  making  some  different  modifications  to  one  factor  or  two  of  the  existing  protocol,  but  as  we  know  that  every  factor  is  not  completely  unrelated  to  others,  so  by  just  ignoring  the  impact  of  change  in  one  parameter  of  the  protocol  on  others  is  not  convincing.So  It  becomes  necessary  to  compare  all  the  results  together  and  see  that  when  one  factor  is  redu ced  then  its  impact  on  all  whole  internet.  Here  its  an  attempt  to  study  the  wholesomeness  internet  performance  and  improve  it.  3 CONVERGENCE TIME A  study  of  packet  delivery  performance  during  routing  convergence  have  shown  that  network  failures  happen  frequently,  and  that  existing  routing  protocols  converge  slowly  after  a  failure.  During  these  routing  co nvergence  periods,  some  packets  may  already  be  enro ute  to  their  destinations  and  new  packets  may  be  sent.  These  on  the  way  packets  can  encounter  routing  loops,  delays ,  and  losses  [1].  Sometimes  BGP  takes  a  substantial  amount  of  time  and  messages  to  conv erge  and  stabilize  following  the  failure  of  some  node  in  the  Internet.  A  very  common  technique  Route  Flap  Damping  was  introduced  in  BGP  protocol  to  minimize  the  impact  of  relatively  unsta ble  routes,  and  almost  all  router  manufactu rers  use  this  ap ‐ proach  in  the ir  routers.  Cisco  and  Juniper  use  in  their  routers  to  deliberately  delay  route  calc ulat ions  to  increase  stability.  But  flip  side  of  RFD  is  the  that  sometime  it  can  delay  the  network  converge nce,  through  simulation  re ‐ sults  it  has  been  observed  that  route  flap  damping  can  significantly  exacerbate  the  convergenc e  times  of  rela ‐ tively  stable  routes[3].  A  new  mechanism  BGP ‐ RCN,  that  provides  an  upper  bound  of  O(d)  on  routing  convergence  delay  for  BGP,  where  d  is  the  network  diameter  as  meas ‐ ured  by  the  number  of  AS  hops.  BGP ‐ RCN  lets  each  rout ‐ ing  update  message  carry  the  information  about  the  spe ‐ cific  cause  which  triggered  the  update  message.  Once  a  node  v  receives  the  first  update  message  triggered  by  a  link  failure,  v  can  avoid  using  any  paths  that  have  been  obsolete  by  the  same  failure  [10].   4 SCALABILITY Whenever  we  try  to  reduce  the  amount  of  time  taken  to  converge,  we  try  to  keep  most  of  the  information  about  alternative  paths  to  the  destination  in  the  router .  But  if  we  do  not  carefully  look  at  the  entries  coming  into  the  rout ‐ ing  table  after  a  failure  or  change  in  network,  then  routing  table  entries  may  increase  to  a  point  where  it  becomes  difficult  to  ma nage  it.  Network  operators  and  dev elopers  have  shown  their  concern  about  the  routing  table  grow ‐ ing  at  alarming  rate  which  has  potential  to  affect  entire  Internet.  The  Int erne t  continues  along  a  path  of  seemingly  inexorable  growth,  at  a  rate  that  has,  at  a  mini mum,  dou ‐ bled  in  size  each  y e ar .  How  big  it  needs  to  be  to  meet  fu ‐ ture  demands  remains  an  area  of  somewhat  va g u e  specu ‐ lation.  Of  more  direct  interest  is  the  question  of  whether  the  basic  elements  of  the  Internet  can  be  extended  to  meet  such  levels  of  future  demand,  whatev er  they  may  be.  To  rephrase  this  question,  are  there  inherent  limitations  in  the  technology  of  the  Internet—or  its  architecture  of  de ‐ ployment—that  may  impact  the  continued  growth  of  the  Internet  to  meet  ever ‐ expanding  levels  of  demand  [19]?  The  current  Internet  interdomain  routing  system  will  not  be  able  to  scale  properly  to  meet  growing  needs,  re ‐ searchers  have  not  ye t  produced  any  routing  architecture  with  satisfactory  app roach  to  limit  the  growth  of  afore ‐ mentioned  entries.  We  believe  that  we  will  be  facing  in  near  future  a  challenge  to  scale  the  size  of  the  Internet  so  as  the  size  of  ro uti ng  table  entries.  © 2009 Journal of Computing http://sites.google.com/site/jo urnalofcomputing/ JOURNAL OF COMPUTING, VOLUME 1, ISSUE 1, DECEMBER 2009, ISSN: 2151-9617 HTTPS://SITES.GOOGLE.COM/S ITE/JOURNALOFCOMPUTING/ 116 Figure  3:BGP  Routing  Ta b l e  Grow th  Pattern   The  last  critic al  point  wa s  reached  when  the  Internet’ s  routing  system  adopted  strong  address  aggregation  using  CIDR  to  handle  address  scaling  in  the  mid  1990’ s.  While  CIDR  wa s  an  extremely  effective  tactic,  most  experts  agree  that  the  growth  beha vior  of  the  rout ing  table  in  the  last  decade  conf irms  that  the  type  of  address  manag e ‐ ment  require d  by  CIDR  will  not  suffice  to  meet  future  Internet  routing  needs  [1]. . To d a y  the  growing  Internet  needs  a  reasonably  good  ag ‐ gregation  like  CIDR  has  done  last  time  which  can  redu ce  the  size  of  routing  table  and  change  the  wa y  the  routi ng  table  grow .  But  we  its  not  so  easy  because  aggregation  beyond  a  limi t  can  not  help  us  as  we  know  that  it  may  raise  issues  load  balancing  and  other  traffic  engineering.  The  problem  with  the  Internet’ s  rout ing  architecture  is  how  the  interdomain  rout ing  proto col  algorithm  and  its  BGP  implementation  scale  with  the  size  of  the  network.  Po o r  scaling  of  a  rout ing  algorithm  expresses  itself  in  terms  of  rapid  rates  of  growth  of  the  routing  table  si ze.  Po o r  scal ing  of  routing  table  sizes  exacerbates  conver ‐ gence  problem  [5].  Not  only  is  the  communication  over ‐ head  of  BGP  known  to  be  exponential  [1],  but  the  BGP  RT  size  also  appears  to  grow  exponentially  [5]. 5 FAULT MANAGEMENT Even  as  recently  as  a  decade  ago,  the  failure  of  an  Internet  based  system  wou l d  hav e  been  a  relatively  mi ‐ nor  annoya nce.  To d a y ,  however ,  such  failures  have  an  enormous  cost,  make  news  headlines,  and,  above  all,  hav e  serious  consequences  on  our  society .  The  coming  ye a r s  will  see  the  reach  of  the  Internet  extending  wider  than  ever  before,  and  together  with  this  increasing  reac h  will  come  a  need  for  robust  operation  far  more  stringent  than  in  the  past.  These  dual  trends,  one  a  “technology  push”  towar d  pervasiv eness  driven  by  the  integration  of  com ‐ puting,  wireless  communication,  and  sensing  technolo ‐ gies  on  small  devices,  and  the  other  a  demand  pull  driv en  by  the  use  of  networks  as  a  critical  component  of  the  wo rl d ’ s  information  sys tems,  form  the  backdrop  for  my  research[7].   Fault ‐ tolerance  is  the  ability  to  operate  correctly  under  faulty  conditions.  These  conditions  in  a  network  setting  can  include  the  failure  of  network  components  such  as  physical  link  failure,  node  failure,  and  switch  failures.  Components  within  nodes  can  become  faulty .  Fault  in ‐ stances  can  be  permanent  or  transient,  or  a  combinati on  of  these.  To d a y  we  need  fault  tolerance  in  internet  rout ‐ ing. 6 ROUTING POLICIES The  configurations  of  routing  protocols  determine  how  packets  traverse  each  of  these  levels  of  Internet  topology .  A  routing  protocol  is  responsible  for  exchanging  informa ‐ tion  about  the  state  of  the  network  and  deciding  which  paths  to  use  to  reach  ev ery  destination.  The  output  of  the  routing  protocol  is  a  forwarding  table.  The  primary  role  of  a  routing  protocol  is  to  detect  and  avo id  failed  links,  but  it  also  allows  operators  to  express  preferences  for  dif ‐ ferent  paths  to  shape  how  traffic  flows  across  a  topology .  Routing  between  domains  is  determined  by  policy .  Each  autonomous  system  can,  based  on  configured  policy ,  in ‐ dependently  select  routing  information  from  its  neighbouring  autonomous  systems,  and  selectively  propagate  this  information.  These  policies  are  not  ex ‐ pressed  in  term s  of  hop ‐ distance  to  destin ations  [11].  De ‐ pending  on  how  these  policies  are  constructed,  then,  the  resulting  policy ‐ based  paths  to  destinations  may  inc ur  more  ro uter  level  hops  than  shortest ‐ router ‐ hop  path  routing.  Some  paths  may  be  preferred  because  they  are  lightly ‐ used,  cheaper ,  or  more  reliable.  The  preferences  for  different  paths  constit ute  routing  policy ,  which  ISP  operators  express  in  the  configuration  of  rout ing  proto ‐ cols  [8].   7 ROBUSTNESS AND SECU RITY Wit ho u t  introducing  a  fool proof  security  mechanis m  to  protect  routers  and  their  routing  tables  it  does  not  seem  possible  to  maintain  a  co rrect  flow  of  information  among  desired  sources  and  destinations,  extending  the  networks,  and  servi ces  without  compromises.  But  we  also  unde r ‐ stand  that  securing  Internet  routing  is  a  challenging  task.  We  need  a  flexible  and  scalable  protocol  and  most  impor ‐ tantly ,  a  deployment  strategy ,  since  the  Int ern et  consists  today  of  hun d reds  of  thousands  of  rout ers  and  tens  of  thousands  of  independent  networks  [13].  We  have  seen  from  the  pre vious  experiences  that  a  single  malfun ction ‐ ing  router  can  poison  the  rout ing  tables  of  many  oth e r  routers  on  the  network.   There  va ri o us  issues  like  prefix  hijackin g,  unauthor ‐ ized  advertisement  of  IP  prefixes,  use  of  illegitimate  paths,  spamming,  wor ms ,  trojan  horses,  password  ma ‐ nipulating,  and  phishing  which  we  wish  to  include  in  our  © 2009 Journal of Computing http://sites.google.com/site/jo urnalofcomputing/ JOURNAL OF COMPUTING, VOLUME 1, ISSUE 1, DECEMBER 2009, ISSN : 2151-9617 HTTPS://SITES.GOOGLE.COM/S ITE/JOURNALOFCOMPUTING/ 117 research  work  to  ha ve  reliable  interdomain  routing  proto ‐ col.  8 PROPOSED METHODOL OGY In  our  ap proa ch,  we  plan  to  achieve  expeditious  and  unswerving  routing  R  based  of  the  following  concept:   R=f(T ,S,F ,Se,P o)  Where:  T  is  the  convergence  time  of  boarder  gateway  protocol,  S  is  the  size  of  the  rout ing  table  of  boarder  gateway  protocol,  F  is  fault  tolerance  factor  of  boa rder  gateway  protocol,  Se  is  the  security  factor  of  boa rder  gateway  protocol,  and  Po  is  the  routing  policy  factor  on  boarder  gatewa y  protocol.  That  is  our  proposed  routin g  approach  is  to  optimize  each  above  mentioned  factor  of  boarder  gateway  protocol  to  get  expeditious  and  unswerving  routing  decisions.  To  reduce  the  convergence  time  of  boarder  gatewa y  protocol  we  plan  to  adopt  a  me thod  to  suggest  some  changes  in  design  of  boarder  gateway  protocol  like  treat ‐ ing  the  updates  differently  based  on  their  nature  and  the  ver y  purpose.  We  plan  to  simulate  the  internet  topology  with  many  IS Ps  connected  together  and  then  by  injecting  faults  with  the  help  of  a  separate  node  into  the  simulated  environment  and  will  observe  the  its  time  of  convergence,  and  then  we  will  modify  SSLD,  classi fy  the  updates,  MRAI  timer  mechanisms  to  get  reduced  convergence  time.  We  will  run  simulations  large  number  of  time  to  get  relatively  mo re  accuracy  if  we  get  expected  result  the  changes  will  be  accepted  otherwise  some  other  changes  will  be  done  in  the  design.  An  approach  to  internet  routing  scala bility  and  flexibil ‐ ity  is  to  sepa  rate  the  identification  and  locator  of  a  node  in  the  network.  In  an  architecture  where  one  label  identifies  a  node  and  a  different  label  indicates  its  loca ‐ tion,  topological  changes  will  only  change  the  locators  which  are  assumed  to  follow  topology  and  allow  for  ag ‐ gregation,  and  then  we  pl an  to  introduce  an  addition  translation  mechanis m,  after  labelling  a  tag  to  each  ro uter  belong  to  a  particula r  area,  which  can  translate  it  to  nor ‐ mal  identification  which  can  be  easily  identified  by  route r  of  different  area.  Our  p roposed  approach  is  to  have  a  separate  table  of  disjoint  paths  in  a  sepa rate  database  in  boarder  gateway  protocol  for  each  possi ble  sourc e ‐ destination  pair  if  pos ‐ sible  without  strictly  sticking  to  the  condition  of  selecting  shortest  path.    Whenever  a  failure  oc curs  in  that  situation  the  priorit y  wou ld  be  to  get  a  new  path  from  this  database  of  disjoint  paths  table  to  forw ard  traffic  on  alternate  path.   To  provide  security  and  robustness  to  boa rder  gateway  protocol  we  prop ose  a  strict  met hod  of  content  checking  on  each  update  receiv ed  from  neighbours,  and  if  its  con ‐ tent  shows  intuition  of  ma l ‐ intent  then  that  update  needs  to  be  discarded  and  all  the  paths  going  through  that  router  should  be  dropped  from  the  database  and  a  data ‐ base  of  black  listed  router  should  be  edited.   9 CONCLUSION While  studying  the  behaviour  of  boarder  gateway  pro ‐ tocol  (BGP)  we  found  that  the  convergence  time,  the  number  of  update  messages  exchanged  among  routers,  and  the  size  of  the  rout ing  tables  increase  at  a  rapid  rate  whenever  network  experience  any  change  in  the  network  connectivity/link  failure.  The  entire  network  becomes  over  burd ened  and  congested  while  processing  these  re ‐ quests,  we  sa w  that  sometime  even  a  sin gle  rout e  with ‐ drawal  message  can  trigger  hundreds  of  rout e  withdraw ‐ als  and  new  route  advertisements  and  the  whole  network  of  rout ers  become  overloaded  with  this  wor k  of  stabiliz ‐ ing  that  user  traffic  has  to  suffer  during  this  period.  In  our  proposed  wor k  we  will  limit  the  rate  at  which  these  withdrawal  and  advertisements  emerge  following  a  change  in  network  connectivity  so  that  the  network  can  stabilize  faster  and  will  be  available  mo re  to  support  user  traffic.  We  also  proposed  met hods  to  make  BGP  robus t  and  secure  by  having  a  separate  table  of  disjoint  paths  in  a  separate  database  for  each  possi ble  source ‐ destination  pair  if  possibl e  without  strictly  sticking  to  the  condition  of  selecting  shortest  path.  Whenev er  a  failure  occurs  in  that  situation  the  priority  wou l d  be  to  get  a  new  path  from  this  database  of  disjoint  paths  table  to  forward  traffic  on  alternate  path.   R EFERENCES [1] Crag  Labovitz,  Abha  Ahuja,  Abhijit  Bose,  Farnam  Ja hanian  “De ‐ layed  Internet  Routing  Convergence ”  in  Proc.  of  ACM  SIG ‐ COMM’00 ,  Aug.  2000.  [2]  Dan  P ei,  Lan  Wa n g ,  Daniel  Massey ,  et.  al.,  “A  Study  of  Pa c k e t  Delivery  P erfo rmance  During  Routing  Convergence”,  Proceed ‐ ings  of  the  2003  IEEE  International  Conference  on  Dependable  Sys ‐ tems  and  Networks(DSN ʹ 03) ,  Pa g e ( s) :  183 ‐ 192,  Ye a r  :2003.  [3]  Zhuoqing  Morley  Mao,  Rames h  Govindan,  George  Varghese,  and  Randy  H.  Katz  “Route  Flap  Damping  Exacerbates  Internet  Routing  Convergence” .,  Proceedings  of  the  2002  SIGCOMM  conference.  Pages:  221 ‐ 233  Year  of  Publication:  2002  [4]  Zhi ‐ Li  Zhang  Jaideep  Chandrashekar ,  and  Z henhai  Dua n,  Limit ‐ ing  Pa t h  Exploration  in  BGP  INFOCOM  2005.  24th  Annual  Joint  Conference  of  the  IEEE  Compute r  and  Com munications  Socie ‐ ties.  Proceedings  IEEE,  March  2005  page(s):  2337 ‐ 2348  vol.  4  [5]  Dmitri  Krioukov ,  Kevin  Fall,  KC  Claffy ,  and  Arthur  Brady  “  On  Compact  Routing  for  the  Internet”,  ACM  SIGCOMM  Computer  Communication  Review ,  Vo l u m e  37,  Number  3,  July  2007,  pag ‐ es:42 ‐ 52  [6]  Duato,  J.,  Casado,  R.,  Bermudez,  A.,  Quiles,  F.J.,”  Influence  of  network  size  and  load  on  the  per formance  of  reconfiguration  protocols”,  Network  Computing  and  Applications,  2001.  NCA  2001.  IEEE  International  Symposium  on,  Page(s):  46  –57,  2001.  [7]  Nick  Feamster ,  David  G.  Andersen,  Hari  Balakrishnan,  and  M.  © 2009 Journal of Computing http://sites.google.com/site/jo urnalofcomputing/ JOURNAL OF COMPUTING, VOLUME 1, ISSUE 1, DECEMBER 2009, ISSN: 2151-9617 HTTPS://SITES.GOOGLE.COM/S ITE/JOURNALOFCOMPUTING/ 118 Frans  Kaashoek,   Measuring  the  Effec ts  of  Internet  Pa t h  Faults  on  Reactive  Routing .,  Joint  International  Conference  on  Meas ‐ urement  and  Modeling  of  Computer  Syste ms , Proceedings  of  the  2003  ACM  SIGMETRICS  international  conference  on  Meas ‐ urement  and  modeling  of  compu ter  systems.   San  Diego,  CA,  USA,  Pa g e s :  126  –  137  Ye a r :  2003  [8]  Neil  Timothy  Spring,  Efficient  discovery  of  network  topolo gy  and  routing  policy  in  the  Internet,  Ph  D  dissertatio n,  University  of  Wa s h i n g t o n ,  ye ar  2004,  A v ailable  from  www .cs.umd.edu/~ns pring/papers/nsprin g ‐ thesis  [9]  Ye h u d a  Afe k,  Anat  Bre mler ‐ Barr ,  and  Shemer  Schwarz,  Im ‐ proved  BGP  Convergence  via  Ghost  Fl ushing,  IN FOCOM  2003.  Tw e n t y ‐ Second  Annua l  Jo in t  Conference  of  the  IEEE  Computer  and  Communications .  IEEE  Societies  Publication  Date:  30  March ‐ 3  April  2003  Vo l u m e :  2,  On  page(s):  927 ‐ 937  vol. 2  [10]  Dan  Pei,  Matt  Azuma,  Dan  Massey ,  and  Lixia  Zhang,  im  prov ‐ ing  BGP  convergence  thr ough  r oot  cause  notifi cation.  El sevier  Computer  Networks,  Vo l u m e  48,  Issue  2,  6  June  2005,  Pa g e s  175 ‐ 194.  [11] Hongsuda Ta ngmunarunki t, Ramesh Go vindan, S cott Shenk er, and Deborah Estrin, The Impact of Routing Policy on Internet Paths, INFOCO M  2001.  T wentieth  Annual  Joint  Conference  of  the  IEEE  Computer  and  Communications  Societies.  Proceed ‐ ings.  IEEE Computer and Communications, Societies. Proceed- ings, IEEE, Publication Date: 2001 pages: 736- 742 vol.2  [12]  Timothy  G.  Griffin,  F.  Bruce  Shepherd,  and  Gordon  Wilfong,  The  Stable  Pa t h s  Problem  and  Interdomain  Routin g,  IEEE/ACM  Tr a n s a c t i o n s  on  Networking  ,  Vo l u m e  10,  Issue  2,  Pa g e s :  232  –  243,  Ye a r :  2002  [13]  George  Siganos,  Michalis  Faloutsos,  Improving  the  Security  and  Robustness  of  Internet  Routing:  What  Can  We  Do  To d a y ?  A vailable  at  www .cs.ucr .edu/~siga nos/papers/security.pdf  [14]  Feng  Wa n g ,  Jian  Qiu,  “ On  Understanding  T ransient  Interdo ‐ main  Routi ng  Failures,  IEEE/ACM  TR ANSACTIONS  ON  NETWORKING,  VOL.  17,  NO.  3,  JUNE  2009  [15]  Ve r n  Pa x s o n ,  End ‐ to ‐ En d  Routing  Behavior  in  the  Internet,  IEEE/ACM  TRANSACTIONS  ON  NETWORKING,  VOL.  5,  NO.  5,  OCTOBER  1997  [16]  Bassa m  Halabi,  Internet  Routi ng  Architectures,  2 nd  Editio n,  Cisco  Press.  [17]  Y.  Rekhter,  T.  Li,  Border  Gatew ay  Protocol  4,  Rfc  1771,  SRI  Network  Information  Center,  July  1995.  [18]  Y.  Rekhter ,  T.  Li,  S.  Hares,  Border  Gatew ay  Protocol  4,  A vailable  from   October  2003.  [19]http://www.cisco.com/en/US/docs/ios/iproute/configuration/gui ‐ de           Dr Shishir Kumar is currently working as Associate Professor in the department of Computer Science and Engineering; He is also Head of the Computer Science and Engieering Department, in Jaypee Institute of Engineering and Technology, Guna, Madh ya Pradesh, India. His academic qualification is Ph. D. (Computer Science) with more than 12 years of expe rience in rsearch and teaching. Mahesh Kumar is currently a lecturer in the department of Computer Science and Engineering in Jaypee Institute of Engineering and T echnology , Guna, Madhya Pradesh, India, He has received is M. T ech. degree in Inform ation T echnolog y from Punjabi Un iversity , Patiala. He has more than 8 years of experience of managing computer networks (Cisco routers, switches, firewalls), and teaching.  © 2009 Journal of Computing http://sites.google.com/site/jo urnalofcomputing/

Original Paper

Loading high-quality paper...

Comments & Academic Discussion

Loading comments...

Leave a Comment