idnits 2.17.1 draft-shyam-hipi-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 105 has weird spacing: '...lent to the a...' -- The document date (January 26, 2020) is 1552 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5395 (ref. '4') (Obsoleted by RFC 6195) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT S. Bandyopadhyay 3 draft-shyam-hipi-00.txt January 26, 2020 4 Intended status: Experimental 5 Expires: July 26, 2020 7 Host Identification with Provider Independent Address 8 draft-shyam-hipi-00.txt 10 Abstract 12 This is a protocol to identify a host with a provider independent 13 address. It is useful to identify a host uniquely in a multihomed 14 environment where each host gets associated with more than one 15 provider assigned addresses. By means of associating a host with a 16 provider independent address, customers/customer networks will be 17 able to retain their number even after changing their service 18 provider(s). 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on July 26, 2020. 37 Copyright Notice 39 Copyright (c) 2020 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. 49 1. Introduction 51 Provider independent (PI) addressing can be conceived as naming a 52 host with a number. It can be used by customer networks who would 53 like to retain their number even after changing their service 54 provider; also it is useful to designate a host uniquely if the 55 customer network is multihomed. Just like in name services, as an 56 address needs to be resolved corresponding to a name to initiate 57 communication, the same is required for PI addressing. Each globally 58 unique PI address will be associated to at least one global unicast 59 provider assigned (PA) address. For a host with single interface, 60 this number will be same as the number of service providers the 61 customer network is associated with. This protocol resolves PA 62 addresses associated with a PI address with the approach of DNS. Out 63 of the entire internet protocol addresses, it expects same size of 64 address space to be allocated to PI addresses as the address space 65 allocated for provider assigned unicast addresses. As specified in 66 section 3.2.1 of the architectural specification[1], it assumes 67 address space with prefix ``00" will be assigned for PA addresses and 68 address space with prefix ``01" will be assigned for PI addresses. 70 2. PI address resolution 72 This section tries to come up with a solution for PI address 73 resolution with the approach of DNS[2] with necessary differences. 74 Just like name space in DNS, entire address range with prefix 01 will 75 be the address space used by PI addresses. Servers that will hold the 76 information of mapping between PI addresses and corresponding PA 77 addresses will be called as PIMapServers and the programs that will 78 be used to resolve addresses will be called as PIMapResolvers. 80 In case of DNS where name is used in hierarchical format to resolve 81 the addresses, PI address resolution will be based on the prefix of 82 the PI address used for resolution. The prefix is determined based 83 on the architectural model used for the internet. Based on the prefix 84 information addresses of a list of servers can be found out that will 85 act as regional servers which will be used to resolve mapped PA 86 addresses corresponding to that PI address. A prefix will serve a 87 fixed address space within entire PI address space. Address space 88 belonging to a prefix will be distributed within customer networks of 89 heterogeneous sizes. Address space allocation and the mapping of 90 associated PA address(es) will be assigned by a regional authority. 91 The regional authority will be fully responsible for the operation of 92 regional servers in that region. 94 Like DNS, there are some root servers which will have some fixed 95 addresses, under which there are some prefixes which will act as top- 96 level-domains. In case of CIDR based hierarchy, these prefixes may be 97 of different prefix lengths which are selected based on the 98 requirements. Each prefix in a top level domain can further be split 99 into number of prefixes with the approach of CIDR. This tree 100 structured hierarchy will be kept on growing till we get prefixes 101 associated with regional servers. Each prefix associated with a 102 regional server will be distributed amongst customer networks of 103 various sizes as well as prefixes that will again be associated with 104 some regional servers with the approach of CIDR. These regional 105 servers can be considered as equivalent to the authoritative name 106 servers of DNS which are associated with zones. As stated earlier, 107 prefixes starting with "00" will be assigned for provider assigned 108 addresses and prefix starting with "01" will be assigned for provider 109 independent addresses where as prefix starting with "1" will be 110 assigned for addresses of all other types. 112 As inherent hierarchy is involved in "Mesh structured hierarchy", 113 this hierarchy goes up to two levels. As usual, there will be some 114 root servers with fixed assigned addresses. Each root server will 115 have prefixes with "01.A" that will act like top level domain. Under 116 each top level domain, there will be entries with prefixes "01.A.B". 117 Within a region "A.B", every global PA address is represented as 118 "00.A.B.C.user-id". In order to support customer networks of 119 heterogeneous sizes with the approach of VLSM, the "user-id" portion 120 is further divided as "subnet-id.user-id". So, the effective network 121 prefix of a customer network in PA address space is "00.A.B.C.pa- 122 subnet-id". Within an "A.B", entire PI address space with prefix 123 "01.A.B" will be distributed within customer networks of 124 heterogeneous sizes. So, effective network prefix of a customer 125 network with PI address will be "01.A.B.pi-subnet-id". A particular 126 prefix "01.A.B.pi-subnet-id" will be mapped to at least one provider 127 assigned prefix of same prefix length. For a multihomed customer 128 network within "A.B" that receives services from two service 129 providers will have prefixes "00.A.B.C1.pa-subnet-id1" and 130 "00.A.B.C2.pa-subnet-id2". A PI address prefix "01.A.B.pi-subnet-id" 131 of same length will be mapped to both these prefixes of PA address 132 space. Every region "A.B" will have regional server and backup 133 server(s) with a maximum limit (say 4) with net addresses 134 "00.A.B.server1", "00.A.B.server2", "00.A.B.server3" and 135 "00.A.B.server4". 137 Each PIMapServer will have a database of records that will have 138 information to resolve PI addresses. In memory copy of a region will 139 have an array of records where each record will have the following 140 format: 142 +------------+---------+------+-----+-------+-----------+ 143 | NetAddress | NetMask | Type | TTL | NAddr | Addr(1-4) | 144 +------------+---------+------+-----+-------+-----------+ 145 First two fields "NetAddress/NetMask" represents the PI address range 146 of a network. "Type" will be either Domain/Referral/Individual/ 147 SingleEntry/Default based on which a query and rest of the fields of 148 a record have to be processed. A PI address can have maximum four 149 mapped PA addresses. "Addr1", "Addr2", "Addr3", "Addr4" will hold the 150 corresponding PA addresses and "NAddr" will hold the number of such 151 addresses. The field "TTL" is a 32 bit integer measured in seconds 152 which will hold same meaning and approach as defined in the 153 specification of DNS[2]. When a server receives a query for an 154 address "X", it extracts the record of the network based on 155 "NetAddress/NetMask" and "X" from its database. If no matching record 156 is found, a negative response is sent. Based on the "Type" of the 157 record, the query is processed in the following manner. 159 Type=Domain: 161 This is the most common type. If a customer network would not like to 162 maintain a map server opts for this option. In this case there will 163 be one to one mapping between a PI address and corresponding PA 164 addresses. The fields "Addr1"/"Addr2"/"Addr3"/"Addr4" will hold the 165 PA Net Addresses corresponding to the PI address of the network. 166 Server will send the matching record to the resolver with 167 Type=Domain. Resolver will extract the user-id portion of "X" and 168 find the corresponding mapped PA addresses based on 169 "Addr1"/"Addr2"/...etc. 171 Theoretically, "A.B" portion of a PI address need not match with the 172 "A.B" portion of the corresponding PA addresses. Consider a large 173 corporate that has its corporate office and a branch office within 174 the same region of a particular "A.B" and some other offices with 175 different values of "A.B". The corporate can maintain a contiguous 176 range of PI addresses for the ease of its operation. It needs to 177 split entire PI address range based on its offices and assign the 178 corresponding PA addresses. In order to minimize the path of a query 179 it is desirable that "A.B" of a PI address and its corresponding 180 mapped PA addresses belong to the same region. 182 Type=Referral: 184 This is used when an address within the domain "NetAddress"/"NetMask" 185 has to be processed by another map server. The map server may itself 186 be another regional server or a server within a customer network. 188 When a customer network would like to have a direct control for the 189 mapping of its addresses it needs to opt for this option. 190 "Addr1"/"Addr2"/"Addr3"/"Addr4" of the database entry will hold the 191 pointer to the information associated to each map server. "NAddr" 192 will hold the number of map servers that can be referred. Information 193 of each server will hold the following values: PI address of the map 194 server + Number of PA addresses to reach the map server + PA 195 addresses of the map server. Any one of these map servers need to be 196 queried for further processing. A server may act either in recursive 197 mode or in iterative mode based on its implementation just like in 198 DNS. A large corporate may have different offices and each (or some 199 of them) may maintain a map server based on their policies. 201 When a server needs to handle a particular address separately, it 202 needs to set "NetAddress" with that particular address and all the 203 bits of "NetMask" will be set to "1". The "Type" field has to be set 204 as "SingleEntry"(which is similar to the Type Address(A) in terms of 205 DNS). If some of its addresses need to be handled separately but for 206 the rest common rule may apply (like Type=Domain), records of the 207 individual entries should be processed first and then for the rest. 208 In these cases "Type" has to be set as "Default". So, a server of a 209 customer network may have database entries with Type=Domain/Referral 210 /SingleEntry/Default. It makes sense for a server (or a master file) 211 to have entries with Type=Default, but from the point of a resolver, 212 it does not make any sense. So a server needs to extract the PA 213 addresses and form a record with Type=SingleEntry and send it back to 214 the resolver. 216 For a host having multiple interfaces, each interface may be assigned 217 PA addresses supplied by all the service providers, but it is 218 desirable that PI address gets mapped to only one of them (preferably 219 for a CE router, the interface which will have the shortest path will 220 be mapped PI address with the PA address associated with that CE 221 router). 223 Type=Individual: 225 This is meant for the individual users opting for services like 226 telephonic services that need to maintain PI address. With this 227 option a mobile user may maintain its PI address after changing its 228 service provider. A map server needs to maintain some networks with a 229 range of PI addresses in its database. When a query for an address 230 "X" is received, server needs to get the corresponding record where 231 "Addr1" will hold the pointer to a open file descriptor (or pointer 232 to the in memory copy) of a separate data file where there will be 233 one to one mapping between PI address and its corresponding PA 234 address of all the assigned PI addresses. These networks and 235 assignment of individual PI addresses have to be done by the regional 236 authority. 238 As with Type=Default, Type=Individual does not make any sense to a 239 resolver. So, server needs to extract PA address and form a record 240 with Type=SingleEntry and send it back to the resolver. 242 As stated above, this solution is based on the approach of DNS. For 243 the ease of implementation and to make use of the existing source 244 code related to DNS (e.g. BIND) most of the features have been taken 245 from DNS. DNS supports multiple entry output, but they appear in a 246 sequential manner. In order to make processing easier, they are 247 arranged in a structured manner in this document. 249 IANA has assigned a port for its UDP/TCP based 250 implementation. 252 2.1. Record Format 254 Each record (the way they will appear in a master file or will be 255 used for communication) will have the following format: 257 NetAddress/NetMask + Type (8 bit unsigned int) + + RDATA (Type 258 specific information) 260 Record types are primarily the types of records as described above 261 along with three other types: SOA (Start of a zone of authority), MPS 262 (host with Type=SingleEntry that acts as a Map server for this zone) 263 and DFL (Data File). These types are mainly useful in the context of 264 processing AXFR/IXFR/NOTIFY/DFAXFR/DFIXFR messages. 266 Types are defined as follows: 268 Types values comments 269 ----------------------------------------------------------- 270 SEN (SingleEntry) 1 same as type A(address) in DNS 271 MPS (MapServer) 2 Map server 272 DMN (Domain) 3 273 DEF (Default) 4 274 REF (Referral) 5 275 SOA (Start of a zone) 6 276 IND (Individual) 7 277 DFL (Data File) 8 278 ----------------------------------------------------------- 280 RDATA of different types will appear as follows: 282 Type=SOA: 283 PI address of server+SERIAL+REFRESH+RETRY+EXPIRE+MINIMUM (meaning and 284 values of SERIAL/REFRESH/RETRY/EXPIRE/MINIMUM are same as they were 285 defined in section 3.3.13 of RFC 1035[3]) 287 Type=(SEN/MPS): 288 NAddr(Number of addresses) + corresponding PA addresses 289 Type=(DMN/DEF): 290 NAddr(Number of addresses) + corresponding Net addresses 292 Type=REF: 293 NAddr(Number of map server) + for each map server (PI address of map 294 server + NAddr(Number of addresses of map server) + corresponding PA 295 addresses)) 297 Type=IND: 298 NAddr(=1) + full path name of the data file 300 Type=DFL: 301 Data file name + SERIAL + Number of records in the data file(32 bit 302 unsigned int) 304 While used in communication data file name is used as its length (8 305 bit unsigned int) followed by the octets of the string. 307 TTL value of a record has to be set to 0 if it is not relevant or to 308 accept the value associated with the record of SOA. 310 2.2. Messages 312 In order to support most of the features of DNS, message format has 313 been retained almost same as that of DNS. So, all the relevant fields 314 will be processed exactly in the same manner as that have been done 315 in DNS and all the irrelevant issues have to be ignored. Rest of this 316 section describes where and how changes have to be made. 318 As defined in RFC 1035, the top level format of message is divided 319 into 5 sections (some of which are empty in certain cases) shown 320 below: 322 +---------------------+ 323 | Header | 324 +---------------------+ 325 | Question | the question for the name server 326 +---------------------+ 327 | Answer | answering part of the question 328 +---------------------+ 329 | Authority | authoritative map server 330 +---------------------+ 331 | Additional | additional information 332 +---------------------+ 334 The header section has been retained as defined in RFC 5395[4] as 335 follows: 337 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 338 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 339 | ID | 340 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 341 |QR| OpCode |AA|TC|RD|RA| Z|AD|CD| RCODE | 342 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 343 | QDCOUNT/ZOCOUNT | 344 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 345 | ANCOUNT/PRCOUNT | 346 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 347 | NSCOUNT/UPCOUNT | 348 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 349 | ARCOUNT | 350 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 352 The question section will have two parts: 353 QType(one octet unsigned int)+QData. 355 Query types are defined as follows: 357 QTypes values comments 358 ----------------------------------------------------------- 359 SEN 1 query for mapped PA address 360 SOA 6 query information related to SOA 361 DFL 8 query information related to data file 362 DFXFR 249 data file transfer 363 DFIXFR 250 incremental data file transfer 364 IXFR 251 incremental authoritative data file xfr 365 AXFR 252 authoritative data file transfer 366 ----------------------------------------------------------- 368 QData will hold values based on QType. 370 Following section describes issues related to QType=SEN. Issues 371 related to all other QTypes (i.e. related to file transfer) will be 372 discussed afterwords. 374 For QType=SEN(1): QData=PI address that needs to be resolved. 376 The answer section, authority section and additional section will 377 have a number of resource records where the number will be specified 378 in the header. 380 On receiving a query, map server will return the matching record from 381 its database. If response is address, the answer section will hold 382 the record of any one of these two types: SEN/DMN. 384 If Type=DMN, resolver needs to extract the mapped addresses as 385 described in section 2. 387 If Type=DMN, entire address range will appear in the form of 388 NetAddress/NetMask. This will have advantages while catching data for 389 any particular address, but getting the information of the entire 390 address range. 392 If the response is referral, answer section will be empty and the 393 authoritative section will hold the record with Type=REF. 395 If server supports recursion, for each iterative process that it 396 receives a record with Type=REF, it needs to push the record to the 397 additional section of the message that needs to be sent to the 398 resolver. So, additional section will hold the records of Type=REF of 399 the chain of the tree through which PA addresses have been resolved. 401 2.3. Master file and data file 403 Section 5 of RFC 1035 states: 405 "Master files are text files that contain RRs in text form. Since 406 the contents of a zone can be expressed in the form of a list of RRs 407 a master file is most often used to define a zone, though it can be 408 used to list a cache's contents." 410 Section 5.1 of RFC 1035 states: 412 "The format of these files is a sequence of entries. Entries are 413 predominantly line-oriented, though parentheses can be used to 414 continue a list of items across a line boundary, and text literals 415 can contain CRLF within the text. Any combination of tabs and spaces 416 act as a delimiter between the separate items that make up an entry. 417 The end of any line in the master file can end with a comment. The 418 comment starts with a ";" (semicolon)." 420 Master files follow the same approach and format in the line of DNS 421 as described in section 5 of RFC 1035 with necessary differences. 423 An example master file may look like as follows: 425 @ "PI NetAddr"/"Net Mask" SOA "PI address of primary server" ( 426 20 ; SERIAL 427 7200 ; REFRESH 428 600 ; RETRY 429 3600000; EXPIRE 430 60) ; MINIMUM 431 "PI NetAddr"/"Net Mask" MPS 0 NAddr "PA addresses" 432 "PI NetAddr"/"Net Mask" SEN 0 NAddr "PA addresses" 433 "PI NetAddr"/"Net Mask" DMN 0 NAddr "Net addresses" 434 "PI NetAddr"/"Net Mask" DEF 0 NAddr "Net addresses" 435 "PI NetAddr"/"Net Mask" IND 0 NAddr(=1) "Data file name" 437 A data file contains a sequence of entries where each entry appears 438 in a separate line. Each entry is a mapping between a PI address and 439 its associated PA address separated by space(s). Entries are 440 generally sorted with PI address. As in case of master file comments 441 can be inserted with the start of a ";" (semicolon) that will end at 442 the end of the line. Data files are commonly associated with the map 443 servers maintained by regional authority, but they are not generally 444 associated with the map servers maintained by individual customer 445 networks. A data file entry may appear to be as follows: 447 "PI Address" NAddr "PA Addresses" 449 A map server may have a number of data files. These files have to be 450 defined in another file (a supporting file, the way boot file 451 "named.boot" is used in BIND) that will have information of each of 452 them. An entry in that file will follow the same format of a record 453 (Type=DFL) and will have the following fields: 455 "PI NetAddr"/"NetMask" Type(DFL) TTL "Data File Name" SERIAL "Number 456 of records". 458 This file will be used to process message with QType=DFL which will 459 be used to support data file transfer/incremental data file transfer. 461 For QType=DFL(8): QData="PI NetAddr"/"NetMask" of the desired network 462 For QType=SOA(6): QData="PI NetAddr"/"NetMask" of the desired zone 464 A map server will return a record of Type=DFL on receiving a query 465 with QType=DFL where as it will return a record of Type=SOA on 466 receiving a query with QType=SOA. 468 2.4. Zone maintenance and transfers 470 Section 4.3.5 of RFC 1034 states: 472 "The general model of automatic zone transfer or refreshing is that 473 one of the name servers is the master or primary for the zone. 474 Changes are coordinated at the primary, typically by editing a master 475 file for the zone. After editing, the administrator signals the 476 master server to load the new zone. The other non-master or 477 secondary servers for the zone periodically check for changes (at a 478 selectable interval) and obtain new zone copies when changes have 479 been made. 481 To detect changes, secondaries just check the SERIAL field of the SOA 482 for the zone. In addition to whatever other changes are made, the 483 SERIAL field in the SOA of the zone is always advanced whenever any 484 change is made to the zone." 486 Section 1.2 of RFC 5936 states: 488 "A DNS implementation is not required to support AXFR, IXFR, and 489 NOTIFY, but it should have some means for maintaining name server 490 coherency. A general-purpose DNS implementation will likely support 491 AXFR (and in the same vein IXFR and NOTIFY), but turnkey DNS 492 implementations may exist without AXFR." 494 Zone maintenance and transfer will follow the same approach as DNS 495 with few minor updates. Frequency of update of data files will be 496 high compared to the frequency of update of master file. That is why 497 transfer(/incremental transfer) of data file has been treated 498 separately from the transfer(/incremental transfer) of master file. 500 For all the messages of QType=AXFR/DFXFR/IXFR/DFIXFR, QData="PI 501 NetAddr"/"NetMask" of the desired zone or the desired network. NOTIFY 502 message needs to include which file has been updated followed by the 503 related information. So, if master file has been changed, NOTIFY 504 message with query type SOA will be sent and query type DFL will be 505 sent if a data file has been changed. 507 Transfer of master file will be same as transfer of master file in 508 DNS followed by transfer of all the data files. i.e. processing of 509 AXFR will have the same approach as DNS followed by DFXFR for all the 510 data files. In order to make this happen, at the end of transferring 511 the contents of the master file, server (of AXFR message) needs to 512 send NOTIFY message for all of the data files belonging to that zone 513 to the client(i.e. the secondary server). Processing of NOTIFY of a 514 data file by the secondary server needs to send DFIXFR to the primary 515 if data file already exist; otherwise it needs to send DFXFR. 516 Incremental update of master file (IXFR) will be same as IXFR in DNS 517 with a minor update. If client of IXFR finds a new data file gets 518 introduced, it calls DFXFR corresponding to that data file. Similarly 519 if an entry of a data file gets deleted, client deletes corresponding 520 data file. 522 Processing of DFXFR will have same approach of AXFR in DNS. 523 Similarly processing of DFIXFR will have same approach as IXFR in 524 DNS. While transferring a data file record, an equivalent record of 525 type SEN needs to be sent with the values of PI address and mapped PA 526 address(es) from the record of data file. Where ever a record of type 527 SOA is sent while processing AXFR/IXFR in case of DNS, record of type 528 DFL needs to be sent while processing DFXFR/DFIXFR. 530 For AXFR, IXFR and NOTIFY in DNS, one needs to follow RFC 5936[5], 531 RFC 1995[6] and RFC 1996[7] respectively. 533 3. IANA Consideration 535 IANA has assigned a port number and service name 536 for PI address resolution for both TCP and UDP. 538 4. Security Consideration 540 This document does not include any security related issues. 542 5. Normative References 544 [1] S. Bandyopadhyay, "An Architectural Framework of the Internet 545 for the Real IP World" 546 (work in progress). 548 [2] P.V. Mockapetris., "Domain names - concepts and facilities", 549 RFC 1034, November 1987. 551 [3] P.V. Mockapetris, "Domain names - implementation and 552 specification", RFC 1035, November 1987. 554 [4] D. Eastlake 3rd, "Domain Name System (DNS) IANA 555 Considerations", RFC 5395, November 2008. 557 [5] E. Lewis, A. Hoenes, Ed., "DNS Zone Transfer Protocol (AXFR)", 558 RFC 5936, June 2010. 560 [6] M. Ohta, "Incremental Zone Transfer in DNS", RFC 1995, 561 August 1996. 563 [7] P. Vixie, "A Mechanism for Prompt Notification of Zone Changes 564 (DNS NOTIFY)", RFC 1996, August 1996. 566 6. Author's Address 568 Shyamaprasad Bandyopadhyay 569 HL No 205/157/7, Kharagpur 721305, India 570 Phone: +91 3222 225137 571 e-mail: shyamb66@gmail.com